Re: [PATCH v8 4/4] config: allow http..* any user matching

[Jeff King]

On Mon, Jul 22, 2013 at 05:56:44AM -0700, Kyle J. McKay wrote:

> + matches a url if it refers to the same scheme, host and port and the
> + path portion is an exact match or a prefix that matches at a "/"
> + boundary.  If  does not include a user name, it will match a url
> + with any username otherwise the user name must match as well (the
> + password part, if present in the url, is always ignored).  Longer 
> + path matches take precedence over shorter matches no matter what order
> + they occur in.  For example, if both "https://u...@example.com/path"; and
> + "https://example.com/path/name"; are used as a config  value and
> + then "https://u...@example.com/path/name/here"; is passed to a git
> + command, the settings in the "https://example.com/path/name"; section

These "https://..."; should probably be `https://...`, to mark them in
asciidoc as literals.

-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 v8 4/4] config: allow http..* any user matching

[Jeff King]

On Mon, Jul 22, 2013 at 01:24:06PM -0700, Kyle J. McKay wrote:

> >I am not yet convinced that the precedence rule specified in this
> >what we want (I do not have an example why it is *not* what we want,
> >either).  Another definition could be "if user@ is present in the
> >request, give lower precedence to config entries for the site
> >without user@ than entries with user@", and I do not have a strong
> >opinion myself which one between the two is better (and there may be
> >third and other possible rule).
> >
> >Comments?
> 
> Consider this site:
> [...]

Thanks for explaining, and sorry I missed out on the last few rounds of
review.

I think your scheme (normalization plus special handling of the username
field) addresses my biggest concern, which is matching in the face of
optional usernames. The only two things that make me wary are:

  1. The explanation and special-casing of username is a little
 complicated to explain.

  2. The behavior for resolving the value when faced with multiple
 possibilities is completely unlike the rest of the config system
 (both dropping last-one-wins, and unlike the URL matching for
 credentials).

I think we can decide that (2) is worth it if your semantics are more
flexible in practice. It would be nice to see real-world feedback on how
people use it before setting the behavior in stone, but there's sort of
a chicken and egg problem there.

For (1), I wonder if the explanation would be simpler if the precedences
of each sub-part were simply laid out. That is, would it be correct to
say something like:

  For a config key to match a URL, each element of the config key (if
  present) is compared to that of the URL, in the following order:

1. Protocol (e.g., `https` in `https://example.com/`). This field
   must match exactly between the config key and the URL.

2. Host/domain name (e.g., `example.com` in `https://example.com/`).
   This field must match exactly between the config key and the URL.

3. Path (e.g., `repo.git` in `https://example.com/repo.git`). This
   field is prefix-matched by slash-delimited path elements, so that
   config key `foo/` matches URL `foo/bar`. Longer matches take
   precedence (so `foo/bar`, if it exists, is a better match than
   just `foo/`).

4. Username (e.g., `user` in `https://u...@example.com/repo.git`).

  The list above is ordered by decreasing precedence; a URL that matches
  a config key's path is preferred to one that matches its username.

I don't know if that is more or less clear of an explanation. It makes
more sense to me, but that is probably because I wrote it. I'm also not
100% sure it describes your implementation, but I think it is equivalent
to the prefix matching with normalization.

I have a few other comments on specific patches; I'll send them
separately.

-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

nike free 5.0 damen

[oiwmw]

Fitnesstraining dauert  nike free 5.0 damen
   wirklich eine Maut in den Zoll,
weil jeder eine der Auswirkungen der Füße muss bei jedem Schritt zu
ertragen. Auswählen einer Reihe von Schuhen, die Ihre Schrittlänge innerhalb
der idealen Position landen wird dazu beitragen, Kampf und eine Möglichkeit,
Verletzungen zwingt. Supination und Pronation sind wirklich die Bestimmungen
immer beschreiben rollen Sie Ihre eigenen Füße entweder die auf der
Innenseite oder vielleicht nach außen, wenn die Ferse Hits und Schuhe oder
Stiefel sind wirklich erstellt, kann korrigieren either.A pro Ausübung Shop
ist ein guter Ort, um bekommen die Schrittlänge untersucht und zusätzlich
erhalten Sie eine Empfehlung für die geeignete Art von Turnschuhen. Ein
Schuh, der den Fuß hilft, ohne dass es in unnatürliche Schritt bietet Ihnen
die beste Erfahrung Ausübung eine Möglichkeit, das zu verhindern,
Verletzungen zu vermeiden. Die Leute bei diesen Geschäften kann Verständnis
in der besten Entscheidungen in Unternehmen und Designs bieten.
Ganz einfach, weil Leichtathletik Athleten wirklich sind in Wahrheit die
Popularisierung der Funktion ausgestattet, nike air optimale Schuhe Schuhe,
hat sich das Geschäft bekam bekam bekommen hatte große Fortschritte bei der
Angabe der normalen Kunden eine gute primäre wichtigsten Hauptgrund für den
Kauf ihrer Schuhe geschaffen: die Nike Bedeutung Mode wird als wirklich
modisch betrachtet. Viele verschiedene Markierungen können für eine Vielzahl
von Gelegenheiten, wie die schwarze Farbe gemalt nike air max classic Boot,
das für traditionelle Veranstaltungen ausgelegt wird gefunden werden.
Offenbar sind Menschen wirklich glücklich, weil da Leichtathletik Athleten.
Die bahnbrechende Nike Air Flow Maximum Take entlang rund um die Via ist ein
neuesten Sneaker für die Zehen Stoudemire erlebt. Sie hat bekam diese
innerhalb des aa breite Palette von NBA einen guten Produkten Spiele, die
die Offseason passiert präsentiert bekam.
http://git.661346.n2.nabble.com/file/n7592602/12_2.jpg";
border="0"/>   
Im Jahr 1985 hatte Nike über eine Vision gehalten worden, um einen
Turnschuhe und Laufschuhen für den weißen Mann zu werden. Musste das
psychologische Bild verlassen und zusätzlich Fortschritte im Bereich der
Basketball, genau dort, wo möglich Markt war großartig und auch endete als
tatsächlich in der Lage zu fühlen, ausgenutzt. Sonnenstrahlen Nike bietet
die geniale Idee hatte, mit Michael Jordan, Basketball NBA player pro Statur
brillant kommunizieren. Einer war in der Tat reserviert, alles 5 Jahre und
auch von Nike bezahlt, um eine satte ein paar zusammen mit einem 1/2
Milliarden US-Dollar Dollar Sie von Nike Produkte zu fördern. Eine farbige
neue Layout wurde konzipiert und Titel Michael C. Jordan Air Jordan
produziert. Die 1st Air Jordan Schuhe oder Schuhe glänzten hochwertige
rötlich und auch zusätzlich schwarz Farbton. Als Michael Jordan seine
NBA-Spiele führte im Jahr 1985, ist es ausdrücklich verboten, die NBA in den
Mix von bunt bemalten Schuhe zu widerstehen. In jenen Tagen war Lehrer in
der Tat in der Regel weiß. Allerdings hatte Michael Jordan in der Lage, hohe
Geldstrafen auf der Oberseite des C verhängt gewesen, in Wahrheit, zahlen 
nike free 5.0 v4    zahlte die
Geldstrafen. Für praktisch fast jedem Spiel der TV-Serie, war eigentlich
bestraft und bezahlte Air Jordan Schuhe oder Stiefel. Es war die größte
Werbung Leser warten können und zusätzlich Air Jordan Schuhe oder Stiefel
oder vielleicht Schuhe waren in der Tat war sofort katapultierte die größte
bekannte und noch zusätzlich die massive größere Anzahl von beliebten
Basketball. Von dort hat Air Jordan wirklich Heimkehr, können Sie zu diesem
hervorragenden Tag.



-
Nike Free Run 3 Damen  
nike free 5.0 damen  
nike free 5.0 herren 
--
View this message in context: 
http://git.661346.n2.nabble.com/nike-free-5-0-damen-tp7592602.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] git-clean: implement partial matching for selection

[Jiang Xin]

Document for interactive git-clean says: "You also could say `c` or
`clean` above as long as the choice is unique". But it's not true,
because only hotkey `c` and full match (`clean`) could work.

Implement partial matching via find_unique function to make the
document right.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c  | 80 
 t/t7301-clean-interactive.sh | 40 --
 2 files changed, 90 insertions(+), 30 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index dba8387..3c85e15 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -365,6 +365,56 @@ static void print_highlight_menu_stuff(struct menu_stuff 
*stuff, int **chosen)
string_list_clear(&menu_list, 0);
 }
 
+static int find_unique(const char *choice, struct menu_stuff *menu_stuff)
+{
+   struct menu_item *menu_item;
+   struct string_list_item *string_list_item;
+   int i, len, found = 0;
+
+   len = strlen(choice);
+   switch (menu_stuff->type) {
+   default:
+   die("Bad type of menu_stuff when parse choice");
+   case MENU_STUFF_TYPE_MENU_ITEM:
+
+   menu_item = (struct menu_item *)menu_stuff->stuff;
+   for (i = 0; i < menu_stuff->nr; i++, menu_item++) {
+   if (len == 1 && *choice == menu_item->hotkey) {
+   found = i + 1;
+   break;
+   }
+   if (!strncasecmp(choice, menu_item->title, len)) {
+   if (found) {
+   if (len == 1) {
+   /* continue for hotkey matching 
*/
+   found = -1;
+   } else {
+   found = 0;
+   break;
+   }
+   } else {
+   found = i + 1;
+   }
+   }
+   }
+   break;
+   case MENU_STUFF_TYPE_STRING_LIST:
+   string_list_item = ((struct string_list 
*)menu_stuff->stuff)->items;
+   for (i = 0; i < menu_stuff->nr; i++, string_list_item++) {
+   if (!strncasecmp(choice, string_list_item->string, 
len)) {
+   if (found) {
+   found = 0;
+   break;
+   }
+   found = i + 1;
+   }
+   }
+   break;
+   }
+   return found;
+}
+
+
 /*
  * Parse user input, and return choice(s) for menu (menu_stuff).
  *
@@ -392,8 +442,6 @@ static int parse_choice(struct menu_stuff *menu_stuff,
int **chosen)
 {
struct strbuf **choice_list, **ptr;
-   struct menu_item *menu_item;
-   struct string_list_item *string_list_item;
int nr = 0;
int i;
 
@@ -457,32 +505,8 @@ static int parse_choice(struct menu_stuff *menu_stuff,
bottom = 1;
top = menu_stuff->nr;
} else {
-   switch (menu_stuff->type) {
-   default:
-   die("Bad type of menu_stuff when parse choice");
-   case MENU_STUFF_TYPE_MENU_ITEM:
-   menu_item = (struct menu_item 
*)menu_stuff->stuff;
-   for (i = 0; i < menu_stuff->nr; i++, 
menu_item++) {
-   if (((*ptr)->len == 1 &&
-*(*ptr)->buf == menu_item->hotkey) 
||
-   !strcasecmp((*ptr)->buf, 
menu_item->title)) {
-   bottom = i + 1;
-   top = bottom;
-   break;
-   }
-   }
-   break;
-   case MENU_STUFF_TYPE_STRING_LIST:
-   string_list_item = ((struct string_list 
*)menu_stuff->stuff)->items;
-   for (i = 0; i < menu_stuff->nr; i++, 
string_list_item++) {
-   if (!strcasecmp((*ptr)->buf, 
string_list_item->string)) {
-   bottom = i + 1;
-   top = bottom;
-   break;
-   }
-   }
-   break;
-   }
+   bottom = find_uniq

[PATCH v2] git-clean: implement partial matching for selection

[Jiang Xin]

In the 1st version of this patch, I forgot to remove a shell command for
debug in t7301:

find . > /tmp/x &&

Remove the above command in this version. Sorry about this.

Jiang Xin (1):
  git-clean: implement partial matching for selection

 builtin/clean.c  | 80 
 t/t7301-clean-interactive.sh | 40 --
 2 files changed, 90 insertions(+), 30 deletions(-)

-- 
1.8.3.4.842.g8e6673c

--
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] git-clean: implement partial matching for selection

[Jiang Xin]

Document for interactive git-clean says: "You also could say `c` or
`clean` above as long as the choice is unique". But it's not true,
because only hotkey `c` and full match (`clean`) could work.

Implement partial matching via find_unique function to make the
document right.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c  | 80 
 t/t7301-clean-interactive.sh | 41 +--
 2 files changed, 91 insertions(+), 30 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index dba8387..3c85e15 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -365,6 +365,56 @@ static void print_highlight_menu_stuff(struct menu_stuff 
*stuff, int **chosen)
string_list_clear(&menu_list, 0);
 }
 
+static int find_unique(const char *choice, struct menu_stuff *menu_stuff)
+{
+   struct menu_item *menu_item;
+   struct string_list_item *string_list_item;
+   int i, len, found = 0;
+
+   len = strlen(choice);
+   switch (menu_stuff->type) {
+   default:
+   die("Bad type of menu_stuff when parse choice");
+   case MENU_STUFF_TYPE_MENU_ITEM:
+
+   menu_item = (struct menu_item *)menu_stuff->stuff;
+   for (i = 0; i < menu_stuff->nr; i++, menu_item++) {
+   if (len == 1 && *choice == menu_item->hotkey) {
+   found = i + 1;
+   break;
+   }
+   if (!strncasecmp(choice, menu_item->title, len)) {
+   if (found) {
+   if (len == 1) {
+   /* continue for hotkey matching 
*/
+   found = -1;
+   } else {
+   found = 0;
+   break;
+   }
+   } else {
+   found = i + 1;
+   }
+   }
+   }
+   break;
+   case MENU_STUFF_TYPE_STRING_LIST:
+   string_list_item = ((struct string_list 
*)menu_stuff->stuff)->items;
+   for (i = 0; i < menu_stuff->nr; i++, string_list_item++) {
+   if (!strncasecmp(choice, string_list_item->string, 
len)) {
+   if (found) {
+   found = 0;
+   break;
+   }
+   found = i + 1;
+   }
+   }
+   break;
+   }
+   return found;
+}
+
+
 /*
  * Parse user input, and return choice(s) for menu (menu_stuff).
  *
@@ -392,8 +442,6 @@ static int parse_choice(struct menu_stuff *menu_stuff,
int **chosen)
 {
struct strbuf **choice_list, **ptr;
-   struct menu_item *menu_item;
-   struct string_list_item *string_list_item;
int nr = 0;
int i;
 
@@ -457,32 +505,8 @@ static int parse_choice(struct menu_stuff *menu_stuff,
bottom = 1;
top = menu_stuff->nr;
} else {
-   switch (menu_stuff->type) {
-   default:
-   die("Bad type of menu_stuff when parse choice");
-   case MENU_STUFF_TYPE_MENU_ITEM:
-   menu_item = (struct menu_item 
*)menu_stuff->stuff;
-   for (i = 0; i < menu_stuff->nr; i++, 
menu_item++) {
-   if (((*ptr)->len == 1 &&
-*(*ptr)->buf == menu_item->hotkey) 
||
-   !strcasecmp((*ptr)->buf, 
menu_item->title)) {
-   bottom = i + 1;
-   top = bottom;
-   break;
-   }
-   }
-   break;
-   case MENU_STUFF_TYPE_STRING_LIST:
-   string_list_item = ((struct string_list 
*)menu_stuff->stuff)->items;
-   for (i = 0; i < menu_stuff->nr; i++, 
string_list_item++) {
-   if (!strcasecmp((*ptr)->buf, 
string_list_item->string)) {
-   bottom = i + 1;
-   top = bottom;
-   break;
-   }
-   }
-   break;
-   }
+   bottom = find_uni

Re: [PATCH v2 00/16] First class shallow clone

[Duy Nguyen]

On Wed, Jul 24, 2013 at 5:33 AM, Philip Oakley  wrote:
> In some sense a project with a sub-module is a narrow clone, split at a
> 'commit' object.

Yes, except narrow clone is more flexible. You have to decide the
split boundary at commit time for sub-module, while you decide the
same at clone time for narrow clone.

> There have been comments on the git-user list about the
> problem of accidental adding of large files which then make the repo's foot
> print pretty large as one use case [Git is consuming very much RAM]. The
> bigFileThreshold being one way of spotting such files as separate objects,
> and 'trimming' them.

I think rewriting history to remove those accidents is better than
working around it (the same for accidentally committing password). We
might be able to spot problems early, maybe warn user at commit time
that they have added an exceptionally large blob, maybe before push
time..

The "Git is consuming very much RAM" part is not right. We try to keep
memory usage under a limit regardless of the size of a blob. There may
be some cases we haven't fixed yet. Reports are welcome.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Incompatible '+=' syntax in git-completion.bash

[Matthew Wang]

Hi there,

I noticed a change in commit 734b2f0 on
contrib/completion/git-completion.bash which reverted a syntax fix for
'+=' syntax [1], the syntax does not work for bash < 3.1.  As far as I
know, bash 3.0.x is still widely used on some old servers, could
someone add the fix back again?

Thanks,
Matt

[1] 
https://github.com/git/git/commit/734b2f0532d847a9f566183982f83ddea8d8d197#commitcomment-3664571
--
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 v3 0/6]

[Eric Sunshine]

On Tue, Jul 23, 2013 at 5:26 PM, Philip Oakley  wrote:
> From: "Junio C Hamano" 
> Sent: Tuesday, July 23, 2013 7:26 PM
>> Jakub Narebski  writes:
>>> Junio C Hamano  pobox.com> writes:
 This is mostly unchanged since the previous round, except that

  * The option is spelled "--force-with-lease=:".
Nobody liked "cas" as it was too technical, many disliked
"lockref" because "lock" sounded as if push by others were
excluded by it while in fact this is to fail us.
>>>
>>> Perhaps "--force-gently" ? :-)
>
> Or "--force-carefully" to better indicate the safety / care that is being
> applied?

[bike-shedding: on]

--force-if-safe

[bike-shedding: off]
--
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 2/5] t4211: demonstrate empty -L range crash

[Eric Sunshine]

On Tue, Jul 23, 2013 at 3:03 PM, Junio C Hamano  wrote:
> SZEDER Gábor  writes:
>> You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l  Correct.

Thanks, I like that better.

Unfortunately, what actually got queued on 'next', after applying this
fix-up and re-ordering the patch series, is slightly bogus.  The diff
for f8395edc (range-set: satisfy non-empty ranges invariant) looks
like this:

@@ -67,7 +67,8 @@ test_bad_opts "-L :foo:b.c" "no match"
 # There is a separate bug when an empty -L range is the first -L encountered,
 # thus to demonstrate this particular bug, the empty -L range must follow a
 # non-empty -L range.
-test_expect_failure '-L {empty-range} (any -L)' '
+test_expect_success '-L {empty-range} (any -L)' '
+ n=$(expr $(cat b.c | wc -l) + 1) &&
  n=$(expr $(wc -l http://vger.kernel.org/majordomo-info.html

Re: [PATCH] http: Add http.savecookies option to write out HTTP cookies

[Junio C Hamano]

dborow...@google.com writes:

> From: Dave Borowitz 
>
> HTTP servers may send Set-Cookie headers in a response and expect them
> to be set on subsequent requests. By default, libcurl behavior is to
> store such cookies in memory and reuse them across requests within a
> single session. However, it may also make sense, depending on the
> server and the cookies, to store them across sessions. Provide users
> an option to enable this behavior, writing cookies out to the same
> file specified in http.cookiefile.
> ---

Makes sense.

I briefly wondered if users want to be able to selectively store
cookies only from certain sites but not from others.  But if we are
going to build this on top of Kyle J. McKay's "Per URL http..* 
configuration" series, that will fall out as a natural consequence,
I think.

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

[PATCH] http: Add http.savecookies option to write out HTTP cookies

[dborowitz]

From: Dave Borowitz 

HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single session. However, it may also make sense, depending on the
server and the cookies, to store them across sessions. Provide users
an option to enable this behavior, writing cookies out to the same
file specified in http.cookiefile.

Signed-off-by: Dave Borowitz 
---
 Documentation/config.txt |  6 +-
 http.c   |  7 +++
 t/lib-httpd/apache.conf  |  8 
 t/t5551-http-fetch.sh| 18 ++
 4 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e0b923f..e935447 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1456,7 +1456,11 @@ http.cookiefile::
of the file to read cookies from should be plain HTTP headers or
the Netscape/Mozilla cookie file format (see linkgit:curl[1]).
NOTE that the file specified with http.cookiefile is only used as
-   input. No cookies will be stored in the file.
+   input unless http.saveCookies is set.
+
+http.savecookies::
+   If set, store cookies received during requests to the file specified by
+   http.cookiefile. Has no effect if http.cookiefile is unset.
 
 http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
diff --git a/http.c b/http.c
index 2d086ae..2fbf986 100644
--- a/http.c
+++ b/http.c
@@ -45,6 +45,7 @@ static long curl_low_speed_time = -1;
 static int curl_ftp_no_epsv;
 static const char *curl_http_proxy;
 static const char *curl_cookie_file;
+static int curl_save_cookies;
 static struct credential http_auth = CREDENTIAL_INIT;
 static int http_proactive_auth;
 static const char *user_agent;
@@ -200,6 +201,10 @@ static int http_options(const char *var, const char 
*value, void *cb)
 
if (!strcmp("http.cookiefile", var))
return git_config_string(&curl_cookie_file, var, value);
+   if (!strcmp("http.savecookies", var)) {
+   curl_save_cookies = git_config_bool(var, value);
+   return 0;
+   }
 
if (!strcmp("http.postbuffer", var)) {
http_post_buffer = git_config_int(var, value);
@@ -513,6 +518,8 @@ struct active_request_slot *get_active_slot(void)
slot->callback_data = NULL;
slot->callback_func = NULL;
curl_easy_setopt(slot->curl, CURLOPT_COOKIEFILE, curl_cookie_file);
+   if (curl_save_cookies)
+   curl_easy_setopt(slot->curl, CURLOPT_COOKIEJAR, 
curl_cookie_file);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index dd17e3a..397c480 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,6 +22,9 @@ ErrorLog error.log
 
LoadModule version_module modules/mod_version.so
 
+
+   LoadModule headers_module modules/mod_headers.so
+
 
 
 LockFile accept.lock
@@ -87,6 +90,11 @@ Alias /auth/dumb/ www/auth/dumb/
SetEnv GIT_HTTP_EXPORT_ALL
SetEnv GIT_NAMESPACE ns
 
+
+   SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+   SetEnv GIT_HTTP_EXPORT_ALL
+   Header set Set-Cookie name=value
+
 ScriptAliasMatch /smart_*[^/]*/(.*) ${GIT_EXEC_PATH}/git-http-backend/$1
 ScriptAlias /broken_smart/ broken-smart-http.sh/
 
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 55a866a..287d22b 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -187,6 +187,24 @@ test_expect_success 'dumb clone via http-backend respects 
namespace' '
test_cmp expect actual
 '
 
+cat >cookies.txt 

[PATCH] Documentation/git-clean: fix description for range

[Jiang Xin]

The descriptions of "select by numbers" section for interactive
git-clean are borrowed from git-add, and one sentence should be
replaced.

Signed-off-by: Jiang Xin 
---
 Documentation/git-clean.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 75fb543..8997922 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -111,7 +111,7 @@ select by numbers::
'>>' like this, you can make more than one selection, concatenated
with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9"
to choose 2,3,4,5,7,9 from the list.  If the second number in a
-   range is omitted, all remaining patches are taken.  E.g. "7-" to
+   range is omitted, all remaining items are selected.  E.g. "7-" to
choose 7,8,9 from the list.  You can say '*' to choose everything.
Also when you are satisfied with the filtered result, press ENTER
(empty) back to the main menu.
-- 
1.8.3.2.1052.g3a6d627

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

Re: [PATCH v2 00/16] First class shallow clone

[Philip Oakley]

From: "Duy Nguyen" 
Sent: Tuesday, July 23, 2013 2:20 AM
On Tue, Jul 23, 2013 at 6:41 AM, Philip Oakley  
wrote:

From: "Nguyễn Thái Ngọc Duy" 
Subject: [PATCH v2 00/16] First class shallow clone

It's nice to see that shallow can be a first class clone.

Thinking outside the box, does this infrastructure offer the 
opportunity to

maybe add a date based depth option that would establish the shallow
watermark based on date rather than count. (e.g. the "deepen" SP 
depth could


I've been carefully avoiding the deepen issues because, as you see,
it's complicated. But no, this series does not enable or disable new
deeepen mechanisms. They can always be added as protocol extensions.
Still thinking if it's worth exposing a (restricted form of) rev-list
to the protocol..


Interesting idea.


have an alternate with a leading 'T' to indicate a time limit ratherv 
than
revision count - I'm expecting such a format would be an error for 
existing

servers).

My other thought was this style of cut limit list may also allow a 
big file
limit to do a similar process of listing objects (e.g. blobs) that 
are
size-shallow in the repo, though it maybe a long list on some repos, 
or with

a small size limit.


This one, on the other hand, changes the "shape" of the repo (now with
holes) and might need to go through the same process we do with this
series. Maybe we should prepare for it now. Do you have a use case for
size-based filtering? What can we do with a repo with some arbitrary
blobs missing? Another form of this is narrow clone, where we cut by
paths, not by blob size. Narrow clone sounds more useful to me because
it's easier to control what we leave out.


In some sense a project with a sub-module is a narrow clone, split at a 
'commit' object. There have been comments on the git-user list about the 
problem of accidental adding of large files which then make the repo's 
foot print pretty large as one use case [Git is consuming very much 
RAM]. The bigFileThreshold being one way of spotting such files as 
separate objects, and 'trimming' them.


It doesn't feel right to 'track files and directories` as paths for 
doing a narrow clone - it'd probably fall into the same trap as tracking 
file renames. However if one tracks trees and blobs (as a list of sha1 
values, possibly with their source path) then it should it should be 
possible to allow work on the repo with those empty directories/files in 
the same manner as is used for sub-modules, possibly with some form of 
git-link file as an alternate marker.


The thought process is to map sub-module working onto the other object 
types (blobs and trees). The user would be unable to edit the trimmed 
files/directories anyway, so its sha1 value can't change, allowing it to 
be included in the next commit in the branch series.


Philip


--
Duy
--


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

Re: [PATCH] web--browse: support /usr/bin/cygstart on Cygwin

[Yaakov (Cygwin/X)]

On 2013-06-21 11:06, Junio C Hamano wrote:

From: Yaakov Selkowitz 

While both GUI and console Cygwin browsers do exist, anecdotal evidence
suggests most users rely on their native Windows browser.  cygstart,
which is a long-standing part of the base Cygwin installation, will
cause the page to be opened in the default Windows browser (the one
registered to open .html files).

Signed-off-by: Yaakov Selkowitz 


Will queue and wait for somebody from Cygwin land to comment.


Ping?  Is there someone in particular whose input you are looking for?


Yaakov

--
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] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes

[Joern Hees]

6796d49 introduced a bug by making shared_path == ".git/hg' which
will most likely exist already, causing a new remote never to be
cloned and subsequently causing hg.share to fail with error msg:
"mercurial.error.RepoError: repository .git/hg not found"

Changing gitdir to dirname causes shared_path ==
.git/hg//hg. The call to hg.share with local_path ==
.git/hg//clone works again.

Signed-off-by: Joern Hees 
---
 contrib/remote-helpers/git-remote-hg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/remote-helpers/git-remote-hg 
b/contrib/remote-helpers/git-remote-hg
index 0194c67..89dd4cc 100755
--- a/contrib/remote-helpers/git-remote-hg
+++ b/contrib/remote-helpers/git-remote-hg
@@ -390,7 +390,7 @@ def get_repo(url, alias):
 if not os.path.exists(dirname):
 os.makedirs(dirname)
 else:
-shared_path = os.path.join(gitdir, 'hg')
+shared_path = os.path.join(dirname, 'hg')
 if not os.path.exists(shared_path):
 try:
 hg.clone(myui, {}, url, shared_path, update=False, pull=True)
-- 
1.8.3.3

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

Re: [PATCH v3 0/6]

[Philip Oakley]

From: "Junio C Hamano" 
Sent: Tuesday, July 23, 2013 7:26 PM

Jakub Narebski  writes:


Junio C Hamano  pobox.com> writes:



This is mostly unchanged since the previous round, except that

 * The option is spelled "--force-with-lease=:".
   Nobody liked "cas" as it was too technical, many disliked
   "lockref" because "lock" sounded as if push by others were
   excluded by it while in fact this is to fail us.


Perhaps "--force-gently" ? :-)


Or "--force-carefully" to better indicate the safety / care that is 
being applied?




Hmph.  But we usually use "gently" to mean "do not give the end user
an error message--the caller handles the error itself".

While the option lets you break the usual "must fast-forward" rule,
it is more precise in that the remote ref must be pointing at not
just any ancestor of what you are pushing, but has to be at the
exact commit you specify.

E.g. if you have built one commit on top of the shared branch, and
try to push it with "push --cas=pu:HEAD^ HEAD:pu" (because you know
one commit before the tip is where you started from), your push will
be rejected if somebody else did an equivalent of "reset HEAD~3" on
the receiving end (perhaps because the top commits recorded some
material inappropriate for the project).  Your new commit is still a
decendant of that rewound tip, and usual "must fast-forward" rule
would accept the push, but with "push --cas=pu:HEAD^ HEAD:pu", you
will notice that somebody wanted to rewind the tip and pushing your
work that contains these dropped commit contradicts with that wish.

So I dunno.
--


--
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: getting git from kernel.org is failing

[John Keeping]

On Tue, Jul 23, 2013 at 01:40:05PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
> 
> > then smart HTTP works fine. I wonder if there is a problem in the cgit
> > setup on kernel.org (or if it was even intended that you could fetch
> > from the cgit URL at all; the cgit page shows the clone URLs in
> > /pub/scm/git).
> 
> I didn't think cgit URLs were meant to be clonable, but since
> ls-remote works on them, it seems I thought wrong. :)  Odd.

CGit has a config option "enable-http-clone" which causes it to act as
an endpoint for the dumb HTTP protocol.  That option defaults to "on",
so I suspect that kernel.org has just left it at the default.
--
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] http: Add http.savecookies option to write out HTTP cookies

[dborowitz]

From: Dave Borowitz 

HTTP servers may send Set-Cookie headers in a response and expect them
to be set on subsequent requests. By default, libcurl behavior is to
store such cookies in memory and reuse them across requests within a
single session. However, it may also make sense, depending on the
server and the cookies, to store them across sessions. Provide users
an option to enable this behavior, writing cookies out to the same
file specified in http.cookiefile.
---
 Documentation/config.txt |  6 +-
 http.c   |  7 +++
 t/lib-httpd/apache.conf  |  8 
 t/t5551-http-fetch.sh| 18 ++
 4 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e0b923f..e935447 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1456,7 +1456,11 @@ http.cookiefile::
of the file to read cookies from should be plain HTTP headers or
the Netscape/Mozilla cookie file format (see linkgit:curl[1]).
NOTE that the file specified with http.cookiefile is only used as
-   input. No cookies will be stored in the file.
+   input unless http.saveCookies is set.
+
+http.savecookies::
+   If set, store cookies received during requests to the file specified by
+   http.cookiefile. Has no effect if http.cookiefile is unset.
 
 http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
diff --git a/http.c b/http.c
index 2d086ae..2fbf986 100644
--- a/http.c
+++ b/http.c
@@ -45,6 +45,7 @@ static long curl_low_speed_time = -1;
 static int curl_ftp_no_epsv;
 static const char *curl_http_proxy;
 static const char *curl_cookie_file;
+static int curl_save_cookies;
 static struct credential http_auth = CREDENTIAL_INIT;
 static int http_proactive_auth;
 static const char *user_agent;
@@ -200,6 +201,10 @@ static int http_options(const char *var, const char 
*value, void *cb)
 
if (!strcmp("http.cookiefile", var))
return git_config_string(&curl_cookie_file, var, value);
+   if (!strcmp("http.savecookies", var)) {
+   curl_save_cookies = git_config_bool(var, value);
+   return 0;
+   }
 
if (!strcmp("http.postbuffer", var)) {
http_post_buffer = git_config_int(var, value);
@@ -513,6 +518,8 @@ struct active_request_slot *get_active_slot(void)
slot->callback_data = NULL;
slot->callback_func = NULL;
curl_easy_setopt(slot->curl, CURLOPT_COOKIEFILE, curl_cookie_file);
+   if (curl_save_cookies)
+   curl_easy_setopt(slot->curl, CURLOPT_COOKIEJAR, 
curl_cookie_file);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, pragma_header);
curl_easy_setopt(slot->curl, CURLOPT_ERRORBUFFER, curl_errorstr);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, NULL);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index dd17e3a..397c480 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,6 +22,9 @@ ErrorLog error.log
 
LoadModule version_module modules/mod_version.so
 
+
+   LoadModule headers_module modules/mod_headers.so
+
 
 
 LockFile accept.lock
@@ -87,6 +90,11 @@ Alias /auth/dumb/ www/auth/dumb/
SetEnv GIT_HTTP_EXPORT_ALL
SetEnv GIT_NAMESPACE ns
 
+
+   SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+   SetEnv GIT_HTTP_EXPORT_ALL
+   Header set Set-Cookie name=value
+
 ScriptAliasMatch /smart_*[^/]*/(.*) ${GIT_EXEC_PATH}/git-http-backend/$1
 ScriptAlias /broken_smart/ broken-smart-http.sh/
 
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 55a866a..287d22b 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -187,6 +187,24 @@ test_expect_success 'dumb clone via http-backend respects 
namespace' '
test_cmp expect actual
 '
 
+cat >cookies.txt 

Re: getting git from kernel.org is failing

[Jonathan Nieder]

Jeff King wrote:

> then smart HTTP works fine. I wonder if there is a problem in the cgit
> setup on kernel.org (or if it was even intended that you could fetch
> from the cgit URL at all; the cgit page shows the clone URLs in
> /pub/scm/git).

I didn't think cgit URLs were meant to be clonable, but since
ls-remote works on them, it seems I thought wrong. :)  Odd.

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

Re: getting git from kernel.org is failing

[Jeff King]

On Tue, Jul 23, 2013 at 10:06:05PM +0200, Fredrik Gustafsson wrote:

> Confirmed (tested both with and without trailing /, IIRC there was some
> configuration change recently that effect that):
> iveqy@kolya:~/slask/git$ git clone
> https://git.kernel.org/cgit/git/git.git/
> Klonar till "git"...
> error: Unable to get pack index
> https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx

That's weird. We shouldn't be fetching an index at all unless dumb http
is in use. When I try to clone from the URL above, I also get shunted to
dumb-http (and the repo on the server appears to be poorly packed).

But if I go to:

  https://git.kernel.org/pub/scm/git/git.git

then smart HTTP works fine. I wonder if there is a problem in the cgit
setup on kernel.org (or if it was even intended that you could fetch
from the cgit URL at all; the cgit page shows the clone URLs in
/pub/scm/git).

-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 2/5] t4211: demonstrate empty -L range crash

[SZEDER Gábor]

On Tue, Jul 23, 2013 at 12:03:05PM -0700, Junio C Hamano wrote:
> SZEDER Gábor  writes:
> > (Side question: the test suite is full with similar constructs, i.e.
> > redirecting file contents to stdin, but why not just use wc -l b.c,
> > i.e. let wc open the file?)
> 
> "wc -l  otherwise you will see the filename in the output, and you need to
> somehow strip it if you are only interested in the line count.

Facepalm, that should have been obvious...

--
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: getting git from kernel.org is failing

[Fredrik Gustafsson]

On Tue, Jul 23, 2013 at 09:41:44PM +0200, Stefan Beller wrote:
> git clone https://git.kernel.org/cgit/git/git.git
> Cloning into 'git'...
> error: Unable to get pack index 
> https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
> error: Unable to get pack file 
> https://git.kernel.org/cgit/git/git.git/objects/pack/pack-6bfd3af75af71d7bf66a80d6374ac09245ad3ce5.pack
> The requested URL returned error: 404 Not found
> error: Unable to find bce6db96a333c2d47b07580c5a9207cf10935378 under 
> https://git.kernel.org/cgit/git/git.git
> Cannot obtain needed blob bce6db96a333c2d47b07580c5a9207cf10935378
> while processing commit 5addd1c7531cc644787cd562a3c22a3b714c7d77.
> error: Fetch failed.
> 
> as reported by ivegy on freenode/#git-devel
> 
> Stefan
> 

Confirmed (tested both with and without trailing /, IIRC there was some
configuration change recently that effect that):
iveqy@kolya:~/slask/git$ git clone
https://git.kernel.org/cgit/git/git.git/
Klonar till "git"...
error: Unable to get pack index
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
^C
iveqy@kolya:~/slask/git$ git clone
https://git.kernel.org/cgit/git/git.git
Klonar till "git"...
error: Unable to get pack index
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
error: Unable to find d6b65e204c6009e5c30f358810198319b70eda25 under
https://git.kernel.org/cgit/git/git.git
Cannot obtain needed blob d6b65e204c6009e5c30f358810198319b70eda25
while processing commit 5addd1c7531cc644787cd562a3c22a3b714c7d77.
error: Fetch failed.
fatal: Reading from helper 'git-remote-https' failed
iveqy@kolya:~/slask/git$ 


-- 
Med vänliga hälsningar
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] log: use true parents for diff even when rewriting

[Junio C Hamano]

Thomas Rast  writes:

> +define_commit_slab(saved_parents, struct commit_list *);
> +struct saved_parents saved_parents_slab;
> +static int saved_parents_initialized;
> +
> +void save_parents(struct commit *commit)
> +{
> + struct commit_list **pp;
> +
> + if (!saved_parents_initialized) {
> + init_saved_parents(&saved_parents_slab);
> + saved_parents_initialized = 1;
> + }
> +
> + pp = saved_parents_at(&saved_parents_slab, commit);
> + assert(*pp == NULL);
> + *pp = copy_commit_list(commit->parents);
> +}
> +
> +struct commit_list *get_saved_parents(struct commit *commit)

Use "const struct commit *" here, as combine-diff.c has a const pointer.

> +{
> + if (!saved_parents_initialized)
> + return commit->parents;
> +
> + return *saved_parents_at(&saved_parents_slab, commit);
> +}

clear_commit_slab() is not used, failing -Wunused -Werror compilation.

> diff --git a/revision.h b/revision.h
> index 95859ba..0717518 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -273,4 +273,19 @@ enum rewrite_result {
>  
>  extern int rewrite_parents(struct rev_info *revs, struct commit *commit,
>   rewrite_parent_fn_t rewrite_parent);
> +
> +/*
> + * Save a copy of the parent list, and return the saved copy.  This is
> + * used by the log machinery to retrieve the original parents when
> + * commit->parents has been modified by history simpification.
> + *
> + * You may only call save_parents() once per commit (this is checked
> + * for non-root commits).
> + *
> + * get_original_parents() will transparently return commit->parents if
> + * history simplification is off.
> + */
> +extern void save_parents(struct commit *commit);
> +extern struct commit_list *get_original_parents(struct commit *commit);
> +

s/_original/_saved/ here, and "const struct commit *".

By the way, when the only single parameter is a named type, you can
safely omit the name of the parameter from the declaration without
losing clarity.

>  #endif
> diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
> index 57ce239..fde5e71 100755
> --- a/t/t6012-rev-list-simplify.sh
> +++ b/t/t6012-rev-list-simplify.sh
> @@ -127,4 +127,10 @@ test_expect_success 'full history simplification without 
> parent' '
>   }
>  '
>  
> +test_expect_success '--full-diff is not affected by --parents' '
> + git log -p --pretty="%H" --full-diff -- file >expected &&
> + git log -p --pretty="%H" --full-diff --parents -- file >actual &&
> + test_cmp expected actual
> +'
> +
>  test_done
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 15/16] config: add core.noshallow to prevent turning a repo into a shallow one

[Philip Oakley]

From: "Duy Nguyen" 
Sent: Tuesday, July 23, 2013 2:28 AM
On Tue, Jul 23, 2013 at 2:23 AM, Philip Oakley  
wrote:

From: "Nguyễn Thái Ngọc Duy" 
Subject: [PATCH v2 15/16] config: add core.noshallow to prevent 
turning a

repo into a shallow one

Surely this should be the default now that it is possible to corrupt 
a
golden repo by pushing/fetching a shallow repository to it and it 
then

becomes shallow, and all the followers become shallow as well, with
consequent problems (IIUC) [PATCH v2 05/16].

It would be just as easy to change the config to core.allowshallow 
which
then must be enabled by the user, and can be mentioned in the shallow 
clone

option's documentation.


Clarification, it's not really "corrupt". If you have full history
from a ref "A", fetching from another shallow clone does not touch the
history of ref A at all



  (that is if you do _not_ specify --depth).


I hadn't appreciated this conditional.

It
may add a a shallow ref B, which is the reason the whole repo becomes
shallow.
I had read the initial commit message (in 05/16) as implying that it was 
possible to fool someone into pulling a shallow repo and that would make 
their repo just as shallow (that's without a --depth argument to the 
command). Had that been the case then it would have been possible to 
loose some data from deep in the DAG. Glad to hear I was mistaken. 
Perhaps if your comment above is included in the commit message to 
ensure that clarification is there.



The same goes for push. This is not implemented, but I'm
thinking of adding "clean .git/shallow" to git repack -ad. Then if you
delete ref B and repack -ad, the repo could become full again.

But yeah, maybe defaulting to no shallow is better. Will do so in the
reroll unless someone objects.
--
Duy
--
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

getting git from kernel.org is failing

[Stefan Beller]

git clone https://git.kernel.org/cgit/git/git.git
Cloning into 'git'...
error: Unable to get pack index 
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-1e2bca8b5127039cff42b1cd3d47767fb577cd4f.idx
error: Unable to get pack file 
https://git.kernel.org/cgit/git/git.git/objects/pack/pack-6bfd3af75af71d7bf66a80d6374ac09245ad3ce5.pack
The requested URL returned error: 404 Not found
error: Unable to find bce6db96a333c2d47b07580c5a9207cf10935378 under 
https://git.kernel.org/cgit/git/git.git
Cannot obtain needed blob bce6db96a333c2d47b07580c5a9207cf10935378
while processing commit 5addd1c7531cc644787cd562a3c22a3b714c7d77.
error: Fetch failed.

as reported by ivegy on freenode/#git-devel

Stefan



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/5] t4211: demonstrate empty -L range crash

[Junio C Hamano]

SZEDER Gábor  writes:

> You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l  (Side question: the test suite is full with similar constructs, i.e.
> redirecting file contents to stdin, but why not just use wc -l b.c,
> i.e. let wc open the file?)

"wc -l http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rm: do not set a variable twice without intermediate reading.

[Junio C Hamano]

Stefan Beller  writes:

> On 07/23/2013 08:32 PM, Junio C Hamano wrote:
>> Interesting. This is ancient and dates back to 7612a1ef (git-rm:
>> honor -n flag., 2006-06-08).
> Originally it comes from d9b814cc97 (by Linus), which introduced:
> + seen = NULL;
> + if (pathspec) {
> + for (i = 0; pathspec[i] ; i++)
> + /* nothing */;
> + seen = xmalloc(i);
> + memset(seen, 0, i);
> + }
>
> Then in 7612a1efdb0c the second seen assignment was made unconditional.

That is why I blamed the bug to 7612a1ef.  Before that, without pathspec,
directory traversal function were told not to report which ones were
seen and which ones were not by passing seen=NULL.


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

Re: [PATCH] rm: do not set a variable twice without intermediate reading.

[Stefan Beller]

On 07/23/2013 08:32 PM, Junio C Hamano wrote:
> Stefan Beller  writes:
> 
>> Just the next line assigns a non-null value to seen.
>>
>> Signed-off-by: Stefan Beller 
>> ---
>>  builtin/rm.c | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/builtin/rm.c b/builtin/rm.c
>> index 5b63d3f..df85f98 100644
>> --- a/builtin/rm.c
>> +++ b/builtin/rm.c
>> @@ -316,7 +316,6 @@ int cmd_rm(int argc, const char **argv, const char 
>> *prefix)
>>  parse_pathspec(&pathspec, 0, PATHSPEC_PREFER_CWD, prefix, argv);
>>  refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
>>  
>> -seen = NULL;
>>  seen = xcalloc(pathspec.nr, 1);
>>  
>>  for (i = 0; i < active_nr; i++) {
> 
> Interesting. This is ancient and dates back to 7612a1ef (git-rm:
> honor -n flag., 2006-06-08).
> 

Well the removed line itself maybe, but the next line ... as well.

The next line "seen = xcalloc(...)" was introduced in 29211a93c14
(2013-07-14) and was changed 4 or 5 times before (changing the
the malloc function to xmalloc and then to xcalloc.
I suppose these changes did not pay attention to the local area
around, but rather were interested in making the memory allocation
fast or safe in many places.


Originally it comes from d9b814cc97 (by Linus), which introduced:
+   seen = NULL;
+   if (pathspec) {
+   for (i = 0; pathspec[i] ; i++)
+   /* nothing */;
+   seen = xmalloc(i);
+   memset(seen, 0, i);
+   }

Then in 7612a1efdb0c the second seen assignment was made unconditional.
And since then it has been not noticed. ;)

However that being said, I am currently playing around with different
code analyzers (find dead code, possible null pointers, and such),
and the coding style of git is very different to what I am used to
(and what the tools are used to as well, lots of false positives).

Personally the coding style of git often reminds me to 'C as a
macro-assembler' rather than 'C as a high level programming
language'.

Stefan




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

Re: [PATCH] rm: do not set a variable twice without intermediate reading.

[Junio C Hamano]

Stefan Beller  writes:

> Just the next line assigns a non-null value to seen.
>
> Signed-off-by: Stefan Beller 
> ---
>  builtin/rm.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index 5b63d3f..df85f98 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -316,7 +316,6 @@ int cmd_rm(int argc, const char **argv, const char 
> *prefix)
>   parse_pathspec(&pathspec, 0, PATHSPEC_PREFER_CWD, prefix, argv);
>   refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
>  
> - seen = NULL;
>   seen = xcalloc(pathspec.nr, 1);
>  
>   for (i = 0; i < active_nr; i++) {

Interesting. This is ancient and dates back to 7612a1ef (git-rm:
honor -n flag., 2006-06-08).

--
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 v3 0/6]

[Junio C Hamano]

Jakub Narebski  writes:

> Junio C Hamano  pobox.com> writes:
>
>> 
>> This is mostly unchanged since the previous round, except that
>> 
>>  * The option is spelled "--force-with-lease=:".
>>Nobody liked "cas" as it was too technical, many disliked
>>"lockref" because "lock" sounded as if push by others were
>>excluded by it while in fact this is to fail us.
>
> Perhaps "--force-gently" ? :-)

Hmph.  But we usually use "gently" to mean "do not give the end user
an error message--the caller handles the error itself".

While the option lets you break the usual "must fast-forward" rule,
it is more precise in that the remote ref must be pointing at not
just any ancestor of what you are pushing, but has to be at the
exact commit you specify.

E.g. if you have built one commit on top of the shared branch, and
try to push it with "push --cas=pu:HEAD^ HEAD:pu" (because you know
one commit before the tip is where you started from), your push will
be rejected if somebody else did an equivalent of "reset HEAD~3" on
the receiving end (perhaps because the top commits recorded some
material inappropriate for the project).  Your new commit is still a
decendant of that rewound tip, and usual "must fast-forward" rule
would accept the push, but with "push --cas=pu:HEAD^ HEAD:pu", you
will notice that somebody wanted to rewind the tip and pushing your
work that contains these dropped commit contradicts with that wish.

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

Re: [PATCH v2 3/3] Update po/ja.po

[Junio C Hamano]

Yamada Saburo  writes:

>>> -#: git-gui.sh:2893
>>> +#: git-gui.sh:2983 git-gui.sh:3115
>>> +msgid "Usage"
>>> +msgstr "使用状況"
>> Is this correct?  I am not familiar with the context this string
>> appears, but shouldn't it be "使い方"?
>
> It is a title of the error box which does not have seeing mostly.
> Therefore, I do not understand.
> However, If you wish, it can correct with you yourself another patch later.

Untranslated "Usage" may be understood many Japanese computer users,
but if that label is to show "How to Use", then "使用状況" (whose
literal back-translation is "Usage Status") is a label that makes
things worse, I think. Between this translation and leaving it
untranslated, we may even be better off with the latter.

As the objective of our discussion is to make git-gui's translated
messages better, I _will_ point out an iffy translation that may
make things worse.  It does not have anything to do with what I
wish.

>>> -#: lib/choose_repository.tcl:490
>>> +#: lib/choose_repository.tcl:489
>>>  msgid "Target Directory:"
>>> -msgstr "先ディレクトリ:"
>>> +msgstr "保存ディレクトリ:"
>> I think this is better translation than the original (the Target is
>> about where the new clone appears), but a few lines above we see
>> "Source Location", which may want to be reworded.  Perhaps
>> クローン元リポジトリ
>> クローン先リポジトリ
>> ???
>
> "保存ディレクトリ"(Save Directory) is better. "先ディレクトリ" is very bad.

I already said the original is bad, no?  Cloning to a new place is
different from "Save", and that is why I found that word "保存"
iffy.

>>In short, the translated text is far more alarming than the original
>>phrasing.
>
> Is free translation impossible?

What do you mean "free translation"?  Apparently you do not mean
"free" as in "free beer", as we are both doing these on our own
time, not as a paid task.

Do you mean "I can do whatever I, Yamada Saburo, wish to do?"

It almost appears to me that your position is that any words, as
long as they are written in Japanese, are better than leaving them
in English, even if they are misleading.  I do not think that helps
our users.

The list discussion is "somebody posts a patch, other people eyeball
and suggest improvements, and they collaborate to reach a good
result".  I am involved in the review of this patch not as the Git
maintainer but as somebody who happens to read Japanese, so as I
already said, what I wish does not matter much---what matters is
that the result does not make things worse than leaving them in the
original, untranslated.

I only commented on points in your patch that looked misleading to
those who only get the translated Japanese, without commenting on
others.
--
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 2/5] t4211: demonstrate empty -L range crash

[SZEDER Gábor]

On Tue, Jul 23, 2013 at 10:28:05AM -0400, Eric Sunshine wrote:
> Signed-off-by: Eric Sunshine 
> ---
>  t/t4211-line-log.sh | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
> index 7776f93..1db1edd 100755
> --- a/t/t4211-line-log.sh
> +++ b/t/t4211-line-log.sh
> @@ -64,4 +64,12 @@ test_bad_opts "-L 1,1000:b.c" "has only.*lines"
>  test_bad_opts "-L :b.c" "argument.*not of the form"
>  test_bad_opts "-L :foo:b.c" "no match"
>  
> +# There is a separate bug when an empty -L range is the first -L encountered,
> +# thus to demonstrate this particular bug, the empty -L range must follow a
> +# non-empty -L range.
> +test_expect_failure '-L {empty-range} (any -L)' '
> + n=$(expr $(cat b.c | wc -l) + 1) &&

You could avoid the 'cat' here and patch in 4/5 by doing $(wc -l http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Jul 2013, #03; Tue, 9)

[Junio C Hamano]

Miklos Vajna  writes:

>> How is --ff-only overwriting merge.ff=only here?  Was it a typo?
>
> Yes, it's a typo in the test name. Thanks for spotting that!

Thanks, will do this:

Subject: [PATCH] t7600: fix typo in test title

Spotted by Ram, confirmed by Miklos.

Signed-off-by: Junio C Hamano 
---
 t/t7600-merge.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 3ff5fb8..10aa028 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -502,7 +502,7 @@ test_expect_success 'option --ff-only overwrites --no-ff' '
test_must_fail git merge --no-ff --ff-only c2
 '
 
-test_expect_success 'option --ff-only overwrites merge.ff=only config' '
+test_expect_success 'option --no-ff overrides merge.ff=only config' '
git reset --hard c0 &&
test_config merge.ff only &&
git merge --no-ff c1
-- 
1.8.3.4-985-g5661af8

--
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 0/4] gitk support for git log -L

[Thomas Rast]

Thomas Rast  writes:

> Now that git log -L has hit master, I figure it's time to discuss the
> corresponding change to gitk.

Paul, any news on this?  Any chance we can get it into the next release,
since that will also be the first release to ship with 'git log -L'?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] range-set and line-log bug fixes

[Thomas Rast]

Eric Sunshine  writes:

> While implementing multiple -L support for git-blame, I encountered
> several bugs in range-set and line-log resulting in crashes. This
> series fixes those bugs.

Acked-by: Thomas Rast 

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] Update po/ja.po

[Yamada Saburo]

I wanted the former translator as well as me to correct.
(Or I wanted you good at English to correct Japanese translation by your patch)
I was waiting for someone to have corrected Git-gui Japanese
translation for a long time.
However, nobody corrected.

This is only a translation file. It is not the patch which breaks a system.
Is it necessary to correct at once? Are you unable to correct after
merging this patch by another your patch?

My wish wants to only use Git-gui in honest Japanese. (I hate brainfuck)
you may reject this shoddy patch and you yourself may translate
perfectly, how is it?
I think whether you yourself had better translate. It seems to you
that all my translations are not pleasing.

>> -#: git-gui.sh:2893
>> +#: git-gui.sh:2983 git-gui.sh:3115
>> +msgid "Usage"
>> +msgstr "使用状況"
> Is this correct?  I am not familiar with the context this string
> appears, but shouldn't it be "使い方"?

It is a title of the error box which does not have seeing mostly.
Therefore, I do not understand.
However, If you wish, it can correct with you yourself another patch later.

>> -#: lib/choose_repository.tcl:490
>> +#: lib/choose_repository.tcl:489
>>  msgid "Target Directory:"
>> -msgstr "先ディレクトリ:"
>> +msgstr "保存ディレクトリ:"
> I think this is better translation than the original (the Target is
> about where the new clone appears), but a few lines above we see
> "Source Location", which may want to be reworded.  Perhaps
> クローン元リポジトリ
> クローン先リポジトリ
> ???

"保存ディレクトリ"(Save Directory) is better. "先ディレクトリ" is very bad. (A strange word.
It saw for the first time in life.) "クローン先リポジトリ" is also bad to me. It
is hard to see the difference of only one character.
However, If you wish, it can correct with you yourself another patch later.

>> -#: lib/commit.tcl:272
>> +#: lib/commit.tcl:269
>> +msgid ""
>> +"You are about to commit on a detached head. This is a potentially 
>> dangerous "
>> +"thing to do because if you switch to another branch you will lose your "
>> +"changes and it can be difficult to retrieve them later from the reflog. 
>> You "
>> +"should probably cancel this commit and create a new branch to continue.\n"
>> +" \n"
>> +" Do you really want to proceed with your Commit?"
>> +msgstr ""
>> +"あなたはdetached "
>> +"head状態でコミットしようとしています。これは危険な操作です。もし続行すれば、他ブランチへ切り替えた際に変更を失ったり、reflogで変更を復元することが困難になります。あなたは次の操作をするべきです。1.
>> "
> The line wrapping of this look somewhat fishy.  It technically is
> correct, but ending the line with an explicit \n and closing dq,
> i.e.
> "あなたはdetached head状態...べきです。\n"
> would be more natural and less error prone.
>
> Also, the original says "potentially dangerous", but "potentially"
> is lost in translation.  I am not sure if the difference matters
> very much, but since I noticed it
>
>> +"このコミットをキャンセルする。2. 新しいブランチを作り、コミットし直す。\n"
>
>Also, the original doesn't say "1. cancel this commit. 2. Create a
>new branch to recommit", and it is better without 1./2., which may
>be mistaken as if the user can do one of two things.
>
>> +"\n"
>> +"本当にこの危険なコミットを実行しますか？"
>
>The last sentence in the original only says "your Commit", without
>saying "Dangerous".
>
>In short, the translated text is far more alarming than the original
>phrasing.

Is free translation impossible? I do not understand what for whether
it is a problem.
However, If you wish, it can correct with you yourself another patch later.


>> -#: lib/option.tcl:132
>> +#: lib/option.tcl:134
>>  msgid "Global (All Repositories)"
>> -msgstr "大域（全てのリポジトリ）"
>> +msgstr "標準設定（全てのリポジトリ）"
>The translation reads "Standard", not "Global".  「全体設定」, perhaps?

"標準設定" (Default settings) is better. Or, "グローバル設定"(Global Settings) is
better than "全体設定"(All Settings).
However, If you wish, it can correct with you yourself another patch later.

>> -#: lib/option.tcl:142
>> +#: lib/option.tcl:144
>>  msgid "Merge Verbosity"
>> -msgstr "マージの冗長度"
>> +msgstr "マージのエラー出力レベル (0-5, 標準2、最高5)(merge.verbosity)"
>
> The original does not have 0-5, 2, nor 5.  Translation shouldn't add
> one.
>
> If it will help the users to add these, please first add them to the
> original so that users of all languages would benefit and then
> translate the result.

An English native's person thinks that he does not want to read the
English sentence written by Japanese me.
If you wish, it can correct with you yourself another patch later.

> -#: lib/option.tcl:143
> +#: lib/option.tcl:145
>  msgid "Show Diffstat After Merge"
> -msgstr "マージ後に diffstat を表示"
> +msgstr "マージ後に変更量のグラフを表示 (git diff --stat)"

Ditto.

> -#: lib/option.tcl:150
> +#: lib/option.tcl:153
>  msgid "Minimum Letters To Blame Copy On"
> -msgstr "コピーを検知する最少文字数"
> +msgstr "他ファイルから移動/コピーを検知する最少文字数 (標準値40)"

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

Re: [PATCH v2 05/16] fetch-pack: support fetching from a shallow repository

[Duy Nguyen]

On Tue, Jul 23, 2013 at 9:06 AM, Duy Nguyen  wrote:
> Another is reject new shallow history (i.e.
> no additions to .git/shallow) unless the user explicitly asks so
> either via --depth or a new option --shallow. This does not mean that
> fetching from a shallow clone always fails without either of those
> options.

The above was at pack level when I wrote that, although I think, from
the user perspective, rejecting at ref level makes more sense. That is
if a fetch request returns one ref update with incremental updates and
one with new shallow history, instead of rejecting the whole request,
we reject the second ref update and accept the first one.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] line-log: fix "log -LN" crash when N is last line of file

[Eric Sunshine]

range-set invariants are: ranges must be (1) non-empty, (2) disjoint,
(3) sorted in ascending order.

line_log_data_insert() breaks the non-empty invariant under the
following conditions: the incoming range is empty and the pathname
attached to the range has not yet been encountered. In this case,
line_log_data_insert() assigns the empty range to a new line_log_data
record without taking any action to ensure that the empty range is
eventually folded out.  Subsequent range-set functions crash or throw an
assertion failure upon encountering such an anomaly.  Fix this bug.

Signed-off-by: Eric Sunshine 
---
 line-log.c  | 1 +
 t/t4211-line-log.sh | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/line-log.c b/line-log.c
index 6f94d56..c2d01dc 100644
--- a/line-log.c
+++ b/line-log.c
@@ -299,6 +299,7 @@ static void line_log_data_insert(struct line_log_data 
**list,
p = xcalloc(1, sizeof(struct line_log_data));
p->path = path;
range_set_append(&p->ranges, begin, end);
+   sort_and_merge_range_set(&p->ranges);
if (ip) {
p->next = ip->next;
ip->next = p;
diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 7616365..94267d7 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -72,7 +72,7 @@ test_expect_success '-L {empty-range} (any -L)' '
git log -L1,1:b.c -L$n:b.c
 '
 
-test_expect_failure '-L {empty-range} (first -L)' '
+test_expect_success '-L {empty-range} (first -L)' '
n=$(expr $(cat b.c | wc -l) + 1) &&
git log -L$n:b.c
 '
-- 
1.8.3.4.1120.gc240c48

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

[PATCH 3/5] range-set: satisfy non-empty ranges invariant

[Eric Sunshine]

range-set invariants are: ranges must be (1) non-empty, (2) disjoint,
(3) sorted in ascending order.

During processing, various range-set utility functions break the
invariants (for instance, by adding empty ranges), with the
expectation that a finalizing sort_and_merge_range_set() will restore
sanity.

sort_and_merge_range_set(), however, neglects to fold out empty
ranges, thus it fails to satisfy the non-empty constraint. Subsequent
range-set functions crash or throw an assertion failure upon
encountering such an anomaly. Rectify the situation by having
sort_and_merge_range_set() fold out empty ranges.

Signed-off-by: Eric Sunshine 
---
 line-log.c  | 2 ++
 t/t4211-line-log.sh | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/line-log.c b/line-log.c
index 5234879..6f94d56 100644
--- a/line-log.c
+++ b/line-log.c
@@ -115,6 +115,8 @@ static void sort_and_merge_range_set(struct range_set *rs)
qsort(rs->ranges, rs->nr, sizeof(struct range), range_cmp);
 
for (i = 0; i < rs->nr; i++) {
+   if (rs->ranges[i].start == rs->ranges[i].end)
+   continue;
if (o > 0 && rs->ranges[i].start <= rs->ranges[o-1].end) {
if (rs->ranges[o-1].end < rs->ranges[i].end)
rs->ranges[o-1].end = rs->ranges[i].end;
diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 1db1edd..12814c0 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -67,7 +67,7 @@ test_bad_opts "-L :foo:b.c" "no match"
 # There is a separate bug when an empty -L range is the first -L encountered,
 # thus to demonstrate this particular bug, the empty -L range must follow a
 # non-empty -L range.
-test_expect_failure '-L {empty-range} (any -L)' '
+test_expect_success '-L {empty-range} (any -L)' '
n=$(expr $(cat b.c | wc -l) + 1) &&
git log -L1,1:b.c -L$n:b.c
 '
-- 
1.8.3.4.1120.gc240c48

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

[PATCH 4/5] t4211: demonstrate crash when first -L encountered is empty range

[Eric Sunshine]

Signed-off-by: Eric Sunshine 
---
 t/t4211-line-log.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 12814c0..7616365 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -72,4 +72,9 @@ test_expect_success '-L {empty-range} (any -L)' '
git log -L1,1:b.c -L$n:b.c
 '
 
+test_expect_failure '-L {empty-range} (first -L)' '
+   n=$(expr $(cat b.c | wc -l) + 1) &&
+   git log -L$n:b.c
+'
+
 test_done
-- 
1.8.3.4.1120.gc240c48

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

[PATCH 2/5] t4211: demonstrate empty -L range crash

[Eric Sunshine]

Signed-off-by: Eric Sunshine 
---
 t/t4211-line-log.sh | 8 
 1 file changed, 8 insertions(+)

diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh
index 7776f93..1db1edd 100755
--- a/t/t4211-line-log.sh
+++ b/t/t4211-line-log.sh
@@ -64,4 +64,12 @@ test_bad_opts "-L 1,1000:b.c" "has only.*lines"
 test_bad_opts "-L :b.c" "argument.*not of the form"
 test_bad_opts "-L :foo:b.c" "no match"
 
+# There is a separate bug when an empty -L range is the first -L encountered,
+# thus to demonstrate this particular bug, the empty -L range must follow a
+# non-empty -L range.
+test_expect_failure '-L {empty-range} (any -L)' '
+   n=$(expr $(cat b.c | wc -l) + 1) &&
+   git log -L1,1:b.c -L$n:b.c
+'
+
 test_done
-- 
1.8.3.4.1120.gc240c48

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

[PATCH 1/5] range-set: fix sort_and_merge_range_set() corner case bug

[Eric Sunshine]

When handed an empty range_set (range_set.nr == 0),
sort_and_merge_range_set() incorrectly sets range_set.nr to 1 at exit.
Subsequent range_set functions then access the bogus range at element
zero and crash or throw an assertion failure. Fix this bug.

Signed-off-by: Eric Sunshine 
---

This bug could have been fixed with a simple conditional rather than
changing the for() loop to start at 0. I did it this way, however,
because the next fix (range-set: satisfy non-empty ranges invariant)
also needs the for() loop starting at 0. Thus, by changing the for()
loop here, the subsequent fix becomes much more obvious and easy to
read.

 line-log.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/line-log.c b/line-log.c
index 8cc29a0..5234879 100644
--- a/line-log.c
+++ b/line-log.c
@@ -110,12 +110,12 @@ static void range_set_check_invariants(struct range_set 
*rs)
 static void sort_and_merge_range_set(struct range_set *rs)
 {
int i;
-   int o = 1; /* output cursor */
+   int o = 0; /* output cursor */
 
qsort(rs->ranges, rs->nr, sizeof(struct range), range_cmp);
 
-   for (i = 1; i < rs->nr; i++) {
-   if (rs->ranges[i].start <= rs->ranges[o-1].end) {
+   for (i = 0; i < rs->nr; i++) {
+   if (o > 0 && rs->ranges[i].start <= rs->ranges[o-1].end) {
if (rs->ranges[o-1].end < rs->ranges[i].end)
rs->ranges[o-1].end = rs->ranges[i].end;
} else {
-- 
1.8.3.4.1120.gc240c48

--
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/5] range-set and line-log bug fixes

[Eric Sunshine]

While implementing multiple -L support for git-blame, I encountered
several bugs in range-set and line-log resulting in crashes. This
series fixes those bugs.

Eric Sunshine (5):
  range-set: fix sort_and_merge_range_set() corner case bug
  t4211: demonstrate empty -L range crash
  range-set: satisfy non-empty ranges invariant
  t4211: demonstrate crash when first -L encountered is empty range
  line-log: fix "log -LN" crash when N is last line of file

 line-log.c  |  9 ++---
 t/t4211-line-log.sh | 13 +
 2 files changed, 19 insertions(+), 3 deletions(-)

-- 
1.8.3.4.1120.gc240c48

--
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] open_istream: remove unneeded check for null pointer

[Stefan Beller]

'st' is allocated via xmalloc a few lines before and passed to
the stream opening functions.
The xmalloc function is written in a way that either 'st' is allocated
valid memory or xmalloc already dies.
The function calls to open_istream_* do not change 'st', as the pointer is
passed by reference and not a pointer of a pointer.

Hence 'st' cannot be null at that part of the code.

Signed-off-by: Stefan Beller 
---
 streaming.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/streaming.c b/streaming.c
index acc07a6..debe904 100644
--- a/streaming.c
+++ b/streaming.c
@@ -144,17 +144,17 @@ struct git_istream *open_istream(const unsigned char 
*sha1,
 
st = xmalloc(sizeof(*st));
if (open_istream_tbl[src](st, &oi, real, type)) {
if (open_istream_incore(st, &oi, real, type)) {
free(st);
return NULL;
}
}
-   if (st && filter) {
+   if (filter) {
/* Add "&& !is_null_stream_filter(filter)" for performance */
struct git_istream *nst = attach_stream_filter(st, filter);
if (!nst)
close_istream(st);
st = nst;
}
 
*size = st->size;
-- 
1.8.3.3.1135.ge2c9e63

--
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 v3 0/6]

[Jakub Narebski]

Junio C Hamano  pobox.com> writes:

> 
> This is mostly unchanged since the previous round, except that
> 
>  * The option is spelled "--force-with-lease=:".
>Nobody liked "cas" as it was too technical, many disliked
>"lockref" because "lock" sounded as if push by others were
>excluded by it while in fact this is to fail us.

Perhaps "--force-gently" ? :-)

-- 
Jakub Narębski

--
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] rm: do not set a variable twice without intermediate reading.

[Stefan Beller]

Just the next line assigns a non-null value to seen.

Signed-off-by: Stefan Beller 
---
 builtin/rm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/builtin/rm.c b/builtin/rm.c
index 5b63d3f..df85f98 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -316,7 +316,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
parse_pathspec(&pathspec, 0, PATHSPEC_PREFER_CWD, prefix, argv);
refresh_index(&the_index, REFRESH_QUIET, &pathspec, NULL, NULL);
 
-   seen = NULL;
seen = xcalloc(pathspec.nr, 1);
 
for (i = 0; i < active_nr; i++) {
-- 
1.8.3.3.1135.ge2c9e63

--
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: What's cooking in git.git (Jul 2013, #03; Tue, 9)

[Miklos Vajna]

Hi,

On Tue, Jul 23, 2013 at 12:53:25PM +0530, Ramkumar Ramachandra 
 wrote:
> Junio C Hamano wrote:
> > * mv/merge-ff-tristate (2013-07-02) 1 commit
> >   (merged to 'next' on 2013-07-09 at c32b95d)
> >  + merge: handle --ff/--no-ff/--ff-only as a tri-state option
> 
> Sorry I didn't notice sooner, but I was confused by the second test
> title this added:
> 
> test_expect_success 'option --ff-only overwrites merge.ff=only config' '
>   git reset --hard c0 &&
>   test_config merge.ff only &&
>   git merge --no-ff c1
> '
> 
> How is --ff-only overwriting merge.ff=only here?  Was it a typo?

Yes, it's a typo in the test name. Thanks for spotting that!

Miklos


signature.asc
Description: Digital signature

Re: [PATCH] log: use true parents for diff even when rewriting

[Uwe Kleine-König]

Hello Thomas,

On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote:
> Junio C Hamano  writes:
> > Conceptually I can see how this will change the history
> > simplification in the vertical direction (skipping the ancestry
> > chain and jumping directly to the closest grandparent that touched
> > the specified path), but I am not sure how well this interacts with
> > history simplification in the horizontal direciton (culling
> > irrelevant side branches from the merge).
> 
> But isn't that similarly confusing for the user as Uwe's original
> problem?  Suddenly we'd be showing a merge commit as an ordinary one,
> simply because the merged history did not affect the filtered
> pathspecs.  Thus we would show everything that has been merged on the
> *other* files as a big diff.  Would that be useful?  It would certainly
> be a big difference in how the commit is shown.
the merge is only included in the output if on both parent paths the
file is touched. So this is a non-issue, isn't it? (Well, only if it has
more than 2 parents and not all ancestor paths touch the file, the
number of parents shown is changed.)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] log: use true parents for diff even when rewriting

[Thomas Rast]

Junio C Hamano  writes:

> Thomas Rast  writes:
>
>> When using pathspec filtering in combination with diff-based log
>> output, parent simplification happens before the diff is computed.
>> The diff is therefore against the *simplified* parents.
>>
>> This works okay, arguably by accident, in the normal case: the pruned
>> commits did not affect the paths being filtered, so the diff against
>> the prune-result is the same as against the diff against the true
>> parents.
>>
>> However, --full-diff breaks this guarantee, and indeed gives pretty
>> spectacular results when comparing the output of
>>
>>   git log --graph --stat ...
>>   git log --graph --full-diff --stat ...
>>
>> (--graph internally kicks in parent simplification, much like
>> --parents).

Hmm, I stopped writing the message midway through.  There should be
another two paragraphs here about storing the original parent list on
the side for later use when showing the diff.

>> Perhaps like this.  It's getting a bit late, so I'm not sure if I'm
>> missing another user of the "true" parent list, but it does fix the
>> issue you reported.
>
> Conceptually I can see how this will change the history
> simplification in the vertical direction (skipping the ancestry
> chain and jumping directly to the closest grandparent that touched
> the specified path), but I am not sure how well this interacts with
> history simplification in the horizontal direciton (culling
> irrelevant side branches from the merge).

But isn't that similarly confusing for the user as Uwe's original
problem?  Suddenly we'd be showing a merge commit as an ordinary one,
simply because the merged history did not affect the filtered
pathspecs.  Thus we would show everything that has been merged on the
*other* files as a big diff.  Would that be useful?  It would certainly
be a big difference in how the commit is shown.

> I also have to wonder if we always want to incur this save-parents
> overhead, or we are better off limiting it to only when --full-diff
> is in effect.

I haven't quite convinced myself that it is 100% safe to use the
rewritten parents when --full-diff is not in effect...

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: What's cooking in git.git (Jul 2013, #03; Tue, 9)

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> * mv/merge-ff-tristate (2013-07-02) 1 commit
>   (merged to 'next' on 2013-07-09 at c32b95d)
>  + merge: handle --ff/--no-ff/--ff-only as a tri-state option

Sorry I didn't notice sooner, but I was confused by the second test
title this added:

test_expect_success 'option --ff-only overwrites merge.ff=only config' '
git reset --hard c0 &&
test_config merge.ff only &&
git merge --no-ff c1
'

How is --ff-only overwriting merge.ff=only here?  Was it a typo?

-- 8< --
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 3ff5fb8..aea8137 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -502,7 +502,7 @@ test_expect_success 'option --ff-only overwrites --no-ff' '
test_must_fail git merge --no-ff --ff-only c2
 '

-test_expect_success 'option --ff-only overwrites merge.ff=only config' '
+test_expect_success 'option --no-ff overwrites merge.ff=only config' '
git reset --hard c0 &&
test_config merge.ff only &&
git merge --no-ff c1
--
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