* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Junio C Hamano @ 2012-02-29 8:55 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120229083534.GC14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> When given the "--regexp-ignore-case" (or "-i") option, which originally
>> was designed to affect case sensitivity of the search done in the commit
>> log part, e.g. "log --grep", the matches made with -S/-G pickaxe search is
>> done case insensitively now.
>
> I can't imagine anybody would want to have different case-sensitivity
> options for grepping the commit message versus pickaxe. But even if they
> do, and we later add options to control them individually, we would
> still want the short-and-sweet "-i" to cover the common case of setting
> both. So I think the approach is good.
What you didn't read in the above is that the devilq around "-i" is not in
the case insensitivity switch between log-part grep (--grep/--author) and
patch part grep (-S/-G), but how it interacts with generating the patch
part case insensitively (i.e. "log -p --ignore-case", which is also "-i").
You can see what I decided to do in an evil merge in 'pu'.
In short,
* The short-and-sweet "-i" means both --regexp-ignore-case (grep) and
--ignore-case (diff); and
* The long-hand can be used to ask for case
insensitive grep but case sensitive patch, or vice versa.
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Jeff King @ 2012-02-29 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5rmt3w8.fsf@alter.siamese.dyndns.org>
On Wed, Feb 29, 2012 at 12:55:35AM -0800, Junio C Hamano wrote:
> > I can't imagine anybody would want to have different case-sensitivity
> > options for grepping the commit message versus pickaxe. But even if they
> > do, and we later add options to control them individually, we would
> > still want the short-and-sweet "-i" to cover the common case of setting
> > both. So I think the approach is good.
>
> What you didn't read in the above is that the devilq around "-i" is not in
> the case insensitivity switch between log-part grep (--grep/--author) and
> patch part grep (-S/-G), but how it interacts with generating the patch
> part case insensitively (i.e. "log -p --ignore-case", which is also "-i").
Hmm. So there are actually three potential options to flip. However, I
think the reasoning above is still sound. We could later split
--regexp-ignore-case into two sub-options if we wanted (but like I said,
I doubt anybody will want that; I was more concerned with making sure
that if somebody _does_ want it, we have not painted ourselves into a
corner).
> You can see what I decided to do in an evil merge in 'pu'.
>
> In short,
>
> * The short-and-sweet "-i" means both --regexp-ignore-case (grep) and
> --ignore-case (diff); and
>
> * The long-hand can be used to ask for case
> insensitive grep but case sensitive patch, or vice versa.
Yes, the evil merge looks sane, assuming both topics implement the
desired behavior.
I am a little dubious of the decision in jc/diff-ignore-case to have
"-i" imply "--ignore-case". For "git diff", it makes perfect sense. But
for "git log", it feels wrong. Ignoring case for the regexps is very
common, and ignoring case for the diffs is uncommon (it is, after all, a
feature we have gone many years without, and I don't remember anyone
bringing it up until recently).
As a user, I would be surprised that something common like "git log
--author=junio -i -p" would change diff generation between versions of
git. It's probably not a huge regression, as patches which actually
look different with --ignore-case are relatively rare, so you are
unlikely to see any difference if you trigger it accidentally. But that
just argues to me that it is a feature that one would want to turn on
explicitly, anyway.
-Peff
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Andreas Ericsson @ 2012-02-29 9:30 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Junio C Hamano, Thomas Rast, Luke Diamand, Git List
In-Reply-To: <CAH5451m=6XhRj1osN_Dw7zKvAW-jtru+EbCkRvo8aNRMbJS6bA@mail.gmail.com>
On 02/29/2012 02:18 AM, Andrew Ardill wrote:
> On 29 February 2012 06:20, Junio C Hamano<gitster@pobox.com> wrote:
>> Thomas Rast<trast@inf.ethz.ch> writes:
>>
>>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>>> object that is the<n>th generation grand-parent of the named
>>>>> commit object, following only the first parents.
>>>>>
>>>>> Hang on, *grand*-parents?
>>>>> ...
>>>
>>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>>> confusion about the position of the dashes, that leaves little room for
>>> error.
>>
>> I think we could either go "easier to read but not precise"
>>
>> ... that is the<n>th generation (grand-)parent of ...
>>
>> or "may sound scary but correct"
>>
>> the ancestor reached by walking the first-parent chain<n> times
>>
>> I am not sure which bucket "n-th first-parent ancestor" falls into.
>
> The terms might be too technical, however my understanding was that
> HEAD^n takes<n> steps along a breadth-first traversal of the commit
> tree rooted at HEAD, while HEAD~n uses a depth-first traversal.
>
> A better form for the description might come from that formulation of
> the process, rather than the 'generational' formulation.
>
I doubt it. Most non-programmers have no notion of the difference
between breadth-first and depth-first. You have to work with trees
or graphs in some form before breadth and depth become intuitive
to read in tech docs.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Tilde spec - befuzzled
From: Andreas Ericsson @ 2012-02-29 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Luke Diamand, Git List
In-Reply-To: <7vaa42zrw8.fsf@alter.siamese.dyndns.org>
On 02/28/2012 08:20 PM, Junio C Hamano wrote:
> Thomas Rast<trast@inf.ethz.ch> writes:
>
>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>> object that is the<n>th generation grand-parent of the named
>>>> commit object, following only the first parents.
>>>>
>>>> Hang on, *grand*-parents?
>>>> ...
>>
>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>> confusion about the position of the dashes, that leaves little room for
>> error.
>
> I think we could either go "easier to read but not precise"
>
> ... that is the<n>th generation (grand-)parent of ...
>
(grand-)parent and ancestor are interchangeable while the parentheses
remain, although the former looks a bit clumsier in text.
> or "may sound scary but correct"
>
> the ancestor reached by walking the first-parent chain<n> times
>
> I am not sure which bucket "n-th first-parent ancestor" falls into.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Nelson Benitez Leon @ 2012-02-29 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, peff, sam.vilain, sam
In-Reply-To: <7v62eqzrqm.fsf@alter.siamese.dyndns.org>
On 02/28/2012 08:24 PM, Junio C Hamano wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> Which raises the questions:
>>
>> * Why is this needed? Does git's use of libcurl ignore http_proxy? [1]
>> seems to indicate that libcurl respects <protocol>_proxy
>> automatically.
>>
>> * Why do you (need to?) support HTTP_PROXY when curl doesn't?
>
> Let me add a third bullet point.
>
> I've heard rumors that libcurl on some versions/installations of Mac OS X
> deliberately ignores the environment. For those who agree with Apple, it
> would be a regression if we suddenly start the environment ourselves and
> using it.
Hi Junio, what did you mean by "we start the environment and using it"?
I didn't understand what you mean there..
^ permalink raw reply
* Re: [PATCH 3/3] http: when proxy url has username but no password, ask for password
From: Nelson Benitez Leon @ 2012-02-29 10:46 UTC (permalink / raw)
To: Jeff King; +Cc: git, sam
In-Reply-To: <20120228193125.GA11725@sigill.intra.peff.net>
On 02/28/2012 08:31 PM, Jeff King wrote:
> On Tue, Feb 28, 2012 at 01:56:29PM +0100, Nelson Benitez Leon wrote:
>
>> diff --git a/http.c b/http.c
>> index 79cbe50..68e3f7d 100644
>> --- a/http.c
>> +++ b/http.c
>> @@ -306,7 +306,41 @@ static CURL *get_curl_handle(void)
>> }
>> }
>> if (curl_http_proxy) {
>> - curl_easy_setopt(result, CURLOPT_PROXY, curl_http_proxy);
>> + char *at, *colon, *proxyuser;
>> + const char *cp;
>> + cp = strstr(curl_http_proxy, "://");
>> + if (cp == NULL) {
>> + cp = curl_http_proxy;
>> + } else {
>> + cp += 3;
>> + }
>> + at = strchr(cp, '@');
>> + colon = strchr(cp, ':');
>> + if (at && (!colon || at < colon)) {
>> + /* proxy string has username but no password, ask for password */
>
> Don't parse the URL by hand. Use credential_from_url, which will do it
> for you (and will properly handle things like unquoting the various
> components).
Will do that
>> + char *ask_str, *proxyuser, *proxypass;
>
> Shouldn't these be static globals? If we have multiple curl handles, you
> would want them to share the authentication information we collect here,
> and not have to ask the user again, no?
I didn't think about multiple curl handles, will look at make those static..
>> + strbuf_addf(&pbuf, "Enter password for proxy %s...", at+1);
>> + ask_str = strbuf_detach(&pbuf, NULL);
>> + proxypass = xstrdup(git_getpass(ask_str));
>
> And this should be using credential_fill(), which will let it use
> credential helpers to save passwords, give it the same type of prompt as
> elsewhere, etc.
>
> See Documentation/technical/api-credential.txt, and see how regular http
> auth is handled for an example.
I will try the credential api, I did my patch based on the fedora 16 git
version, which didn't have the credential api (I couldn't git clone at
that moment for the proxy problem so I had to use the source rpm from
fedora).
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Nelson Benitez Leon @ 2012-02-29 10:46 UTC (permalink / raw)
To: Jeff King; +Cc: Sam Vilain, Thomas Rast, git, sam.vilain
In-Reply-To: <20120228193443.GB11725@sigill.intra.peff.net>
On 02/28/2012 08:34 PM, Jeff King wrote:
> On Tue, Feb 28, 2012 at 11:27:41AM -0800, Sam Vilain wrote:
>
>> On 2/28/12 11:15 AM, Jeff King wrote:
>>> Usually we would prefer environment variables to config. So that:
>>>
>>> $ git config http.proxy foo
>>> $ HTTP_PROXY=bar git fetch
>>>
>>> would use "bar" as the proxy, not "foo". But your code above would
>>> prefer "foo", right?
>>
>> Apparently I'm the author of the http.proxy feature, though I barely
>> [snip]
>
> Good point. We sometimes follow this order:
>
> 1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
> it existed)
> 2. git config files (i.e., http.proxy)
> 3. generic system environment (i.e., $http_proxy).
>
> So thinking about it that way, the original patch makes more sense.
So, in PATCH 2/3, apart from expanding the commit message.. do we want
to support HTTP_PROXY or only http_proxy ? HTTP_PROXY seems to not be
very used by existent programs, but support it it's only a gentenv call..
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Matthieu Moy @ 2012-02-29 9:55 UTC (permalink / raw)
To: Jeff King; +Cc: Sam Vilain, Nelson Benitez Leon, Thomas Rast, git, sam.vilain
In-Reply-To: <20120228193443.GB11725@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Good point. We sometimes follow this order:
>
> 1. git-specific environment variables (i.e., $GIT_HTTP_PROXY, if
> it existed)
> 2. git config files (i.e., http.proxy)
> 3. generic system environment (i.e., $http_proxy).
Yes, just like $EDITOR << core.editor << $GIT_EDITOR.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Thomas Rast @ 2012-02-29 11:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20120229091855.GE14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I am a little dubious of the decision in jc/diff-ignore-case to have
> "-i" imply "--ignore-case". For "git diff", it makes perfect sense. But
> for "git log", it feels wrong. Ignoring case for the regexps is very
> common, and ignoring case for the diffs is uncommon (it is, after all, a
> feature we have gone many years without, and I don't remember anyone
> bringing it up until recently).
Doubly so because (to the best of my list-reading efforts) when it was
brought up recently, the interpretation as "case-insensitive diff
generation" was by mistake/misreading.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Incremental updates to What's cooking
From: Zbigniew Jędrzejewski-Szmek @ 2012-02-29 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <7vbooiuj6z.fsf@alter.siamese.dyndns.org>
On 02/29/2012 09:39 AM, Junio C Hamano wrote:
> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl> writes:
>
>> On 02/28/2012 07:53 AM, Junio C Hamano wrote:
>>
>>> * zj/diff-stat-dyncol (2012-02-27) 11 commits
>>> - diff --stat: add config option to limit graph width
>>> - diff --stat: enable limiting of the graph part
>>> - diff --stat: add a test for output with COLUMNS=40
>>> - diff --stat: use a maximum of 5/8 for the filename part
>>> - merge --stat: use the full terminal width
>>> - log --stat: use the full terminal width
>>> - show --stat: use the full terminal width
>>> - diff --stat: use the full terminal width
>>> - diff --stat: tests for long filenames and big change counts
>>> - t4014: addtional format-patch test vectors
>>> - Merge branches zj/decimal-width, zj/term-columns and jc/diff-stat-scaler
>>>
>>> I resurrected the additional tests for format-patch from an earlier round,
>>> as it illustrates the behaviour change brought by "5/8 split" very well.
>> Hi,
>> the resurrected tests are partly duplicated in 4052-stat-output.sh:
>>
>> t4014:
>> ok 75 - small change with long name gives more space to the name
>> ok 76 - a long name is given more room when the bar is short
>> ok 77 - format patch --stat-width=width works with long name *
>> ok 78 - format patch --stat=...,name-width with long name *
>> ok 79 - format patch --stat-name-width with long name *
>> ok 81 - format patch graph part width *
>> ok 82 - format patch ignores COLUMNS *
>> ok 83 - format patch --stat=width with big change *
>> ok 84 - format patch --stat-width=width with big change *
>> ok 85 - partition between long name and big change is more balanced
>>
>> t4052:
>> ok 3 - format-patch graph width defaults to 80 columns
>> ok 4 - format-patch --stat=width with long name
>> ok 5 - format-patch --stat-width=width with long name
>> ok 6 - format-patch --stat=...,name-width with long name
>> ok 7 - format-patch --stat-name-width with long name
>> ok 24 - format-patch ignores too many COLUMNS (big change)
>> ok 28 - format-patch ignores not enough COLUMNS (big change)
>> ok 29 - format-patch ignores statGraphWidth config
>> ok 36 - format-patch --stat=width with big change
>> ok 37 - format-patch --stat-width=width with big change
>> ok 38 - format-patch --stat-graph--width with big change
>> ok 49 - format-patch --stat=width with big change and long name
>> ok 53 - format-patch ignores COLUMNS (long filename)
>>
>> The ones with * are duplicated exactly. They tests run very fast, but
>> maybe the duplicated ones should be culled.
>
> Yeah, probably we should de-dup them.
>
> Compare the behaviour change shown for t4052 and for t4014 by 119c07bf.
> Which one more obviously show the effect of the code change to allow the
> reader judge if the behaviour change is going in a good direction?
t4014 it seems, but mostly because of more descriptive test names.
But this is only true for the ones without *, I think. So the ones with
* can be deleted without losing this advantage.
The ones with * are very similar in t4014 and t4052.
> The style used in t4052 only changes expect_failure to expect_success, and
> the reader has to accept the judgement of the person who wrote the test
> vector and declared "this is the _right_ output!". The way t4014, taken
> from your earlier round, shows the behaviour change shows how the
> expectation changes from the old behaviour to the new one, and the reader
> can see and decide which one is giving a better output.
>
> Actually, the whole reason I didn't notice duplicates in 4052 was because
> of the above X-<.
>
> If we remove duplicates, will 4052 become empty? It would be really nice
> if we do not have to add a new test script for this series, and instead
> add necessary new tests to existing scripts.
t4052 tests show, log, merge, diff and format-patch with basically the
same commands. Separating the tests into different files would require
duplicating a lot of setup code. OTOH, t4014 is only about format-patch,
so the other ones don't fit. I thought it would be better to create a
new file.
-
Zbyszek
^ permalink raw reply
* Re: [PATCH (BUGFIX)] gitweb: Handle invalid regexp in regexp search
From: Jakub Narebski @ 2012-02-29 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ramsay Jones
In-Reply-To: <7vwr76yc6w.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > When using regexp search ('sr' parameter / $search_use_regexp variable
> > is true), check first that regexp is valid.
>
> Thanks.
>
> How old is this bug? Should it go to older maitenance tracks like 1.7.6?
>From what I examined this bug is from the very beginning when gitweb
started to distinguish regexp search and fixed string search in
0e55991 (gitweb: Clearly distinguish regexp / exact match searches, 2008-02-26)
It was present in 1.5.5 (including beginnings of match highlighting, which
trigger this bug).
This bug was present so long without detection because circumstances must
be quite specific: you have to select regexp search, and to provide invalid
regexp. If you know what regexp is, you probably write correct ones...
but there always room for mistake.
--
Jakub Narebski
Poland
^ permalink raw reply
* Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests
From: opticyclic @ 2012-02-29 17:19 UTC (permalink / raw)
To: git
Firstly, why is there no Bug Tracker such as JIRA for the git project?
This mailing list is next to useless for users since searching is
difficult, as is commenting and voting.
Secondly, since one of the alleged reasons for creating git was to not
have to deal with patches, why are pull requests disable and patches
sent to this mailing list?!
I have read https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches
and it doesn't explain it.
I'm sure I don't have to tell you that GitHub has discussions on pull
requests, which are easier to view than the mailing list archives.
So why is it done in the current way?
^ permalink raw reply
* Re: [RFC/PATCH] Make git-{pull,rebase} no-tracking message friendlier
From: Carlos Martín Nieto @ 2012-02-29 17:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqbooit61u.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
On Wed, 2012-02-29 at 09:09 +0100, Matthieu Moy wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > $example is a caller-given string which already contains the whole
> > command (i.e. it's already 'git rebase <upstream branch>' or 'git pull
> > <repository> <branch>').
>
> OK, I didn't remember the exact message.
>
> > In this patch I've moved that command to its own paragraph so the
> > usage part of the output gets more visibility.
>
> I prefer this, yes.
>
> Perhaps we could go further and try to guess a remote and a branch name
> to give in the example. "git push" already does that to some extend:
>
> $ git -c push.default=tracking push
> fatal: The current branch my-branch has no upstream branch.
> To push the current branch and set the remote as upstream, use
>
> git push --set-upstream origin my-branch
>
> i.e. if there's a remote configured, then using it in the example makes
> sense. I'm not sure if using the current branch name in the example
> would also be a good thing (it usually is for "push" because most users
> would push to a branch with the same name on the remote end).
We do show the branch name in the 'remote add' text at the end, so we
should probably try to use it here as well. What I'm assuming is the
most usual case of one remote called 'origin' shouldn't be a problem. I
think I'll suppress the last part of the output when there are remotes
configured, as we can probably assume that the user is aware of them.
I'm tempted to throw out the second block and say to use either 'git
pull $remote $branch' or 'git branch --set-upstream $branch
$remote/$branch' and refer to the documentation for more. After all,
this is an error message, not a man page.
>
> It may also make sense not to suggest "git remote add" if there's
> already a remote configured. Otherwise, the case, which is probably the
> most common, of:
>
> git clone http://example.com/repo
> cd repo
> git checkout -b new-branch
> git pull
>
> is made far more complex than it should for the newcommer.
Indeed. Removing the last part is probably better for everyone.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] pickaxe: allow -i to search in patch case-insensitively
From: Junio C Hamano @ 2012-02-29 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120229091855.GE14181@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Hmm. So there are actually three potential options to flip. However, I
> think the reasoning above is still sound.
Yes, the grep side of the things is easier to understand and explain if
only one option controlled the case insensitivity or whatever aspect of
the search: "It is like searching things in 'log -p' output!"
^ permalink raw reply
* Re: [PATCH 4/3] parse-options: disallow --no-no-sth
From: René Scharfe @ 2012-02-29 18:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, git, Bert Wesarg, Geoffrey Irving,
Johannes Schindelin, Pierre Habouzit, Jeff King
In-Reply-To: <7vlinmy80x.fsf@alter.siamese.dyndns.org>
Am 28.02.2012 22:15, schrieb Junio C Hamano:
> René Scharfe<rene.scharfe@lsrfire.ath.cx> writes:
>
>> Now that options whose definition starts with "no-" can be negated
>> by removing said "no-", there is no need anymore to allow them to
>> be negated by adding a second "no-", which just looks silly.
>
> Thanks. But accepting them silently and do what the user would have
> expected, especially if we do not advertise it, would not hurt anybody,
> no?
Yes, that's why I didn't include this fourth patch from the beginning.
However, I understood your comment "Among the existing 13 that you
listed, I do not think there is any that tempts any existing user to ask
for negation with "--no-no-foo" form, so I think we should be Ok." to
mean that nobody uses the double-no form of the existing negative
options anyway, and therefore we should disallow it.
Please drop this extra patch if I misunderstood you, in order to keep
backward compatibility.
René
^ permalink raw reply
* Re: [PATCH 2/3] http: try standard proxy env vars when http.proxy config option is not set
From: Junio C Hamano @ 2012-02-29 18:15 UTC (permalink / raw)
To: Nelson Benitez Leon; +Cc: Thomas Rast, git, peff, sam.vilain, sam
In-Reply-To: <4F4E003C.1050301@seap.minhap.es>
Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> writes:
> On 02/28/2012 08:24 PM, Junio C Hamano wrote:
>
>> I've heard rumors that libcurl on some versions/installations of Mac OS X
>> deliberately ignores the environment. For those who agree with Apple, it
>> would be a regression if we suddenly start the environment ourselves and
>> using it.
>
> Hi Junio, what did you mean by "we start the environment and using it"?
> I didn't understand what you mean there..
The reason you didn't understand is because the statement does not parse
X-<. Thanks for pointing it out.
What I meant was that on these platforms, allegedly (note that I do not
have a first-hand experience with them), user's http_proxy environment
setting did not affect libcurl based applications and that is a deliberate
platform decision to give precedence to proxy settings the platform has
elsewhere. The users who agree with this platform decision are happily
using the proxy settings stored elsewhere in the platform with git, but
may have http_proxy environment pointing at a proxy that they do not want
to use for git.
If we suddenly start reading from http_proxy environment ourselves and
explicitly telling libcurl to use the proxy specified, it will change the
behaviour for these users, i.e. a regression.
^ permalink raw reply
* Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests
From: Brian Gernhardt @ 2012-02-29 18:23 UTC (permalink / raw)
To: opticyclic; +Cc: git
In-Reply-To: <CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com>
On Feb 29, 2012, at 12:19 PM, opticyclic wrote:
> Secondly, since one of the alleged reasons for creating git was to not
> have to deal with patches, why are pull requests disable and patches
> sent to this mailing
On the contrary, the design of git was created with the idea of handling patches via e-mail in mind. Tools like git-format-patch, git-am, and git-send-email exist to allow this workflow. Linus wanted a tool that would automate and enhance the way the kernel ML already did work instead of demanding that they change.
~~ Brian G
^ permalink raw reply
* [PATCH] Make git-{pull,rebase} message without tracking information friendlier
From: Carlos Martín Nieto @ 2012-02-29 18:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqbooit61u.fsf@bauges.imag.fr>
The current message is too long and at too low a level for anybody to
understand it if they don't know about the configuration format
already.
The text about setting up a remote is superfluous and doesn't help
understand the error that has happened. Explain how to set up the
tracking information, as it's the most likely way to get to the state
the user was expecting.
Also simplify the message we print on detached HEAD to remove clutter
and a reference to branch.<branchname>.merge which is better left for
the documentation.
---
This still needs some shell scripting to figure out whether we'd want
to replace <remote> with a real value. The text gets to the matter of
things and even tells you how to fix it. More text doesn't really add
more useful information, and this isn't a manpage.
I've left the branch --set-upstream in this version as it's probably
the most usual fix for a failing git push.
git-parse-remote.sh | 32 ++++++++++----------------------
git-pull.sh | 2 +-
git-rebase.sh | 2 +-
3 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index b24119d..08adc90 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -60,31 +60,19 @@ error_on_missing_default_upstream () {
if test -z "$branch_name"
then
echo "You are not currently on a branch, so I cannot use any
-'branch.<branchname>.merge' in your configuration file.
-Please specify which branch you want to $op_type $op_prep on the command
-line and try again (e.g. '$example').
-See git-${cmd}(1) for details."
- else
- echo "You asked me to $cmd without telling me which branch you
-want to $op_type $op_prep, and 'branch.${branch_name#refs/heads/}.merge' in
-your configuration file does not tell me, either. Please
-specify which branch you want to use on the command line and
-try again (e.g. '$example').
+tracking information in your configuration file.
+Please specify which branch you want to $op_type $op_prep.
See git-${cmd}(1) for details.
-If you often $op_type $op_prep the same branch, you may want to
-use something like the following in your configuration file:
- [branch \"${branch_name#refs/heads/}\"]
- remote = <nickname>
- merge = <remote-ref>"
- test rebase = "$op_type" &&
- echo " rebase = true"
- echo "
- [remote \"<nickname>\"]
- url = <url>
- fetch = <refspec>
+ $example"
+ else
+ echo "You asked me to $cmd without specifying a branch to
+$op_type $op_prep, and the current branch doesn't have any tracking
+information. Please specify a branch and try again. See git-${cmd}(1)
+for details. To set the tracking information, you can use
-See git-config(1) for details."
+ git branch --set-upstream ${branch_name#refs/heads/} <remote>/<branch>
+"
fi
exit 1
}
diff --git a/git-pull.sh b/git-pull.sh
index d8b64d7..309c7db 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -176,7 +176,7 @@ error_on_no_merge_candidates () {
elif [ -z "$curr_branch" -o -z "$upstream" ]; then
. git-parse-remote
error_on_missing_default_upstream "pull" $op_type $op_prep \
- "git pull <repository> <refspec>"
+ "git pull <remote> <branch>"
else
echo "Your configuration specifies to $op_type $op_prep the ref '${upstream#refs/heads/}'"
echo "from the remote, but no such ref was fetched."
diff --git a/git-rebase.sh b/git-rebase.sh
index 00ca7b9..69c1374 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -380,7 +380,7 @@ then
then
. git-parse-remote
error_on_missing_default_upstream "rebase" "rebase" \
- "against" "git rebase <upstream branch>"
+ "against" "git rebase <branch>"
fi
;;
*) upstream_name="$1"
--
1.7.8.352.g876a6f
^ permalink raw reply related
* Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests
From: Junio C Hamano @ 2012-02-29 18:53 UTC (permalink / raw)
To: opticyclic; +Cc: git
In-Reply-To: <CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com>
opticyclic <opticyclic@gmail.com> writes:
> Firstly, why is there no Bug Tracker such as JIRA for the git project?
Probably because nobody volunteered to set-up, actively de-dupe, triage
and maintain it in general.
> Secondly, since one of the alleged reasons for creating git was to not
> have to deal with patches, why are pull requests disable and patches
> sent to this mailing list?!
I think Brian already corrected whoever "alleges" such.
We prefer to develop in the open, reviewing and improving both patches and
ideas on the mailing list, without having to rely on a single project
hosting site everybody has to go and deal with web based interface.
^ permalink raw reply
* Re: [PATCH 4/3] parse-options: disallow --no-no-sth
From: Junio C Hamano @ 2012-02-29 19:02 UTC (permalink / raw)
To: René Scharfe
Cc: Thomas Rast, git, Bert Wesarg, Geoffrey Irving,
Johannes Schindelin, Pierre Habouzit, Jeff King
In-Reply-To: <4F4E6912.7060204@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Please drop this extra patch if I misunderstood you, in order to keep
> backward compatibility.
I do not think it makes practical difference between accepting silently or
forbidding, so let's stop at 3/3 and keep --no-no-sth working.
Thanks.
^ permalink raw reply
* Re: filtering out mode-change-only changes
From: Neal Kreitzinger @ 2012-02-29 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7vipiqwb2g.fsf@alter.siamese.dyndns.org>
On 2/28/2012 9:52 PM, Junio C Hamano wrote:
> Junio C Hamano<gitster@pobox.com> writes:
>
>> "Neal Kreitzinger"<neal@rsss.com> writes:
>>
>>> What is the best way to filter out the "mode change only" entries from a
>>> "name-status diff result" listing of changed files?
>>> ...
>> I do not know about random scripts people write, but there is nothing
>> built-in.
>
> Having said that, if we _were_ to do this built-in, an obvious logical
> place to do so is to define a new DIFF_OPT_IGNORE_EXECUTABLE_BIT, teach
> "--ignore-executable-bit" command line option to diff_opt_parse(), and
> then teach diff_resolve_rename_copy() to consider this bit when the code
> originally set DIFF_STATUS_MODIFIED. Instead, the updated code that is
> working under --ignore-executable-bit option would drop such a filepair
> from diff_queued_diff.
>
> I do not know if such a change is worth doing, though. It depends on the
> real reason why do you have so many "mode change only" changes that would
> make rebasing or cherry-picking too troublesome.
>
I see three parts to this issue that are related but also independent:
Questions:
(Q1) Is the user handling filemodes correctly in git?
(Q2) Why does the user need to interrogate filemodes in git?
(Q3) How are file modes interrogated by the user in git?
Some Answers:
Q1: Is the user handling filemodes correctly in git?
A1-1: (My Context)
Perhaps I'm not, but I'm not prepared to ignore filemodes. I think I
need to be aware of what's changing. Blasting everything with the linux
chmod 777 shotgun, or the git core.filemode=false shotgun does not seem
like the right answer to me. I need to do more homework on linux
permissions and git executable bit tracking.
A1-2: (General Context)
Some users do legitimately choose to have core.filemode=true and are
correct in doing so.
Q2: Why does the user need to interrogate filemodes in git?
A2-1: (My Context)
After a rebase we need to review what changed with a 4-way diff to have
the full context of merge-base, topic, upstream, and merged. Because we
are mere-mortals, we want to use gui side-by-side diff (ie, diffuse)
instead of 4-way combined diff. git-difftool only takes two file parms
so I have to write my own script. git-mergetool's can display 4-way diff
but insist on mangling the $MERGED file with their own attempts at
redoing the merge, ie. creating their own merge conflicts even though
$MERGED has no conflict markers on input.
A2-2: (General Context)
"Vendor code drops" (see git-rm manpage) can have substantial
file-mode-only changes along with real content changes due to incorrect
tar procedures and/or the vendor's filesystem being a "mode breaking
filesystem". Also, there are these human stdin's going about
capriciously with a free-will doing chmod's.
Q3: How are file modes interrogated by the user in git?
A3-1: (Some Current Options)
--name-status lumps file-mode-only changes and content changes together
under status "M".
--raw can be parsed to discern filemode changes concurrent with
identical content sha1's.
--summary "mode change" entries might also be usable to apply a filter
to --name-status results.
A3-2: (Some Desired Options)
--name-status learns a new status for file-mode-only changes (ie, "P"
for "P"ermissions).
--raw learns "P+x" and "P-x" in the status column to tell you if the
executable bit was added or removed.
I wonder if filemode tracking was somewhat of an afterthought of the
content-is-king design of git and that is why it is semi-opaque.
v/r,
neal
^ permalink raw reply
* Re*: Tilde spec - befuzzled
From: Junio C Hamano @ 2012-02-29 19:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Thomas Rast, Luke Diamand, Git List
In-Reply-To: <4F4DF096.9050905@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> On 02/28/2012 08:20 PM, Junio C Hamano wrote:
>> Thomas Rast<trast@inf.ethz.ch> writes:
>>
>>>>> '<rev>{tilde}<n>', e.g. 'master{tilde}3'::
>>>>> A suffix '{tilde}<n>' to a revision parameter means the commit
>>>>> object that is the<n>th generation grand-parent of the named
>>>>> commit object, following only the first parents.
>>>>>
>>>>> Hang on, *grand*-parents?
>>>>> ...
>>>
>>> Perhaps we should reword it as "n-th first-parent ancestor"? Barring
>>> confusion about the position of the dashes, that leaves little room for
>>> error.
>>
>> I think we could either go "easier to read but not precise"
>>
>> ... that is the<n>th generation (grand-)parent of ...
>
> (grand-)parent and ancestor are interchangeable while the parentheses
> remain, although the former looks a bit clumsier in text.
Ok, then something like this...
-- >8 --
Subject: Documentation: do not assume that n > 1 in <rev>~$n
We explained <rev>~<n> as <n>th generation grand-parent, but a reader got
confused by the "grand-" part when <n> is 1.
Reword it with "ancestor"; with the "generation" and "following only the
first parents" around there, what we try to describe should be clear
enough now.
Noticed-by: Luke Diamand <luke@diamand.org>
Helped-by: Thomas Rast <trast@inf.ethz.ch>
Helped-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index b290b61..1725661 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -101,7 +101,7 @@ the '$GIT_DIR/refs' directory or from the '$GIT_DIR/packed-refs' file.
'<rev>{tilde}<n>', e.g. 'master{tilde}3'::
A suffix '{tilde}<n>' to a revision parameter means the commit
- object that is the <n>th generation grand-parent of the named
+ object that is the <n>th generation ancestor of the named
commit object, following only the first parents. I.e. '<rev>{tilde}3' is
equivalent to '<rev>{caret}{caret}{caret}' which is equivalent to
'<rev>{caret}1{caret}1{caret}1'. See below for an illustration of
^ permalink raw reply related
* Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests
From: Carlos Martín Nieto @ 2012-02-29 19:18 UTC (permalink / raw)
To: opticyclic; +Cc: git
In-Reply-To: <CAM=oOO2i-9zraF-YG5YzvZEmN1eXTnQfhJ-eMF04NP7HGtf41w@mail.gmail.com>
On Wed, 2012-02-29 at 12:19 -0500, opticyclic wrote:
> Firstly, why is there no Bug Tracker such as JIRA for the git project?
Bug trackers aren't magical. Just because a bug is in some sort of
database, it doesn't mean that it's going to get fixed faster. People
work on what they find interesting or their sponsors find important. Bug
databases are also notorious for getting filled with duplicate entries
and languishing bugs that are waiting for the original reporter to
answer with some information that the developers asked. Everyone would
also need to get an account on that bug tracker, making it harder to
report and contribute.
There used to be a wiki for buglets so people could get started, but I'm
not sure if it survived the k.org compromise.
> This mailing list is next to useless for users since searching is
> difficult, as is commenting and voting.
All you need to comment is an e-mail program, which most people have.
gmane also allows you to post from the web interface. What voting are
you referring to? There is no form of formal voting that isn't
restricted to the people responsible (or knowledgeable about) a
particular part of the project. And that's not even really voting, but a
review on the soundness of the patch.
>
> Secondly, since one of the alleged reasons for creating git was to not
> have to deal with patches, why are pull requests disable and patches
> sent to this mailing list?!
Who said git was made to stop dealing with patches? Some of the git
terminology is influenced by that (compare 'git revert' with the idea of
a revert that other systems have). Do you follow the linux mailing list?
It's full of patches waiting to be reviewed.
git does use pull requests. That's how gitk and git-svn are updated, in
the git repository. I believe the git-subtree inclusion request also
took form of a pull request.
> I have read https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches
> and it doesn't explain it.
>
> I'm sure I don't have to tell you that GitHub has discussions on pull
> requests, which are easier to view than the mailing list archives.
Easier to view? Do you mean it's easier on the eyes? Easier to get an
overview? What do you want to view in these discussions? Why do you want
everyone to need a GitHub account to participate in git?
The GitHub web-UI has no threading, which means that you either discuss
all the patches together in one line so it's no longer clear who's
answering what, or you comment on the commit itself, which means that
the whole discussion is at least as segmented as what you get via
e-mail, and you have to scroll more to get to the discussion of a
particular commit.
TL;DR this is the way we've found to be the most effective.
cmn
^ permalink raw reply
* Re: Incremental updates to What's cooking
From: Junio C Hamano @ 2012-02-29 19:28 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <4F4E2D32.9030209@in.waw.pl>
Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> writes:
> t4052 tests show, log, merge, diff and format-patch with basically the
> same commands. Separating the tests into different files would require
> duplicating a lot of setup code. OTOH, t4014 is only about
> format-patch, so the other ones don't fit. I thought it would be
> better to create a new file.
OK, then perhaps we want to move the versions of duplicated one them from
4014 to 4052?
Thanks.
^ permalink raw reply
* Re: Stash during incomplete merge
From: Neal Kreitzinger @ 2012-02-29 19:34 UTC (permalink / raw)
To: Phil Hord; +Cc: git@vger.kernel.org, Phil Hord
In-Reply-To: <4F4D5408.3060505@gmail.com>
On 2/28/2012 4:24 PM, Neal Kreitzinger wrote:
> On 2/28/2012 2:22 PM, Neal Kreitzinger wrote:
>>
>> You may also want to consider the --keep-index option on your "git
>> stash save" if your "testing" workflow doesn't involve adds or
>> commits before the git stash apply/pop.
>>
> the very limited case I had in mind (and probably incorrect
> assumption) about your "testing" workflow was:
>
> hack merge-conflicts $ git add conflict-resolution
> (conflict-resolution is in worktree and index) hack
> conflict-resolution with extra stuff (original conflict-resolution
> is still in index) uh-oh, i got carried away and started doing extra
> stuff (evil merge) and forgot to finish testing just the
> conflict-resolutions (pure merge-commit) $ git stash --keep-index
> (conflict-resolution is still in index and now back in wokrtree)
> finish testing just the conflict-resolutions (merge-commit-to-be)
> (conflict resolutions worked (I knew they would)) $ git stash pop
> (original conflict resolution is still in index, but extra-stuff is
> back in worktree) $ git commit (commit the
> conflict-resolutions/merge-commit) $ git add foo $ git commit (new
> foo stuff committed after merge commit)
>
This imaginary scenario I proposed for --keep-index can get a
merge-conflict on the pop so its invalid. Please disregard it. Sorry
for the bum scoop.
v/r,
neal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox