* Re: possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-28 12:20 UTC (permalink / raw)
To: Baz; +Cc: Git Mailing List
In-Reply-To: <2faad3050910271405k4a391184vb978b9b35484383b@mail.gmail.com>
On Tue, Oct 27, 2009 at 10:05 PM, Baz <brian.ewins@gmail.com> wrote:
> I'm fine with this way of fixing it, but I'd make a few more changes...
Feel free to make a patch-series that addresses more issues - I'm not going to.
We make patches of one change at the time in Git. Other (related)
usability issues becomes separate patches, preferably grouped together
in a patch-series. This change would be one patch in such a series.
>> OPTIONS_SPEC="\
>> git-rebase [-i] [options] [--] <upstream> [<branch>]
>
> Use the dashless form and be more consistent with the help - and
> mention '--root' here, it appears in the
> help below:
>
> -git-rebase [-i] [options] [--] <upstream> [<branch>]
> +git rebase [--interactive | -i] [options] [--onto <newbase>] [--]
> <upstream> [<branch>]
> +git rebase [--interactive | -i] [options] --onto <newbase> --root
> [--] [<branch>]
>
I'm not sure I follow - aren't dashless options, uhm, dashless? Do you
mean to use the long-form instead of the short-form? I'll assume
that's what you mean for now, since you changed "-i" to "--interactive
| -i".
If so, I'm not 100% convinced it's a clear win: some grep'ing
indicates that both the short and long form are both widely used, with
short-option bein a slight favor:
$ git grep " \[--" | grep -v " \[--\]" | wc -l
228
$ git grep " \[-[^-]" | wc -l
243
Also, the usage isn't the only documentation. I think it makes sense
to try to keep the usage short and to the point, there's a list
describing each option (showing the full-name) further down in the
usage-message. And if that's not enough, there's the "git
help"-command.
If I've misunderstood you and you only want the usage-string to match
that of the manpage, perhaps that might be a good idea. I dunno.
>
>> -git-rebase [-i] (--continue | --abort | --skip)
>> +git-rebase [-i] [-m] (--continue | --abort | --skip)
>
> Again, dashless. And I'd not mention the useless -i here, the man page
> doesn't either:
>
> -git-rebase [-i] (--continue | --abort | --skip)
> +git rebase (--continue | --abort | --skip)
>
It was already there, so I didn't consider it, but I guess it makes
sense. Besides, I aimed at not loosing any information while making it
a bit clearer.
> These two items are misplaced in the help (I think). They're not like
> abort, continue, skip, but then, the man page doesn't group those
> separately either.
>
> +no-verify override pre-rebase hook from stopping the operation
> +root rebase all reachable commmits up to the root(s)
>
Agree.
>> Actions:
>> continue continue rebasing process
>> abort abort rebasing process and restore original branch
>
> As above, remove the next two lines after your patch:
>
> -no-verify override pre-rebase hook from stopping the operation
> -root rebase all reachable commmits up to the root(s)
I don't follow this. Are you repeating yourself now? :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: drawbacks to svn server + git-svn vs git server?
From: Matthieu Moy @ 2009-10-28 12:19 UTC (permalink / raw)
To: Dexter Riley; +Cc: git
In-Reply-To: <25994334.post@talk.nabble.com>
Dexter Riley <edbeaty@charter.net> writes:
> Hello. My group is currently using subversion on our version control server,
> but would like to move to git as a client. We are considering using
> git-svn, to avoid revalidating the server software. My question is, are
> there any major disadvantages to using git-svn versus git?
One rather big drawback is that "git svn dcommit" has to do some
history-rewritting. In other words, if you have a local commit A in
your repository, and send it to the SVN server with "git svn dcommit",
then A is rewritten into A' (same tree content, but different commit
message at least, and maybe other details I'm not aware of). If you
use git-svn as a "better SVN client", it's not a problem, but if you
want to really use the Git part of git-svn, then this history
rewritting will break the local branches that reference your A.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH 3/3] diff: fix the location of hunk headers for "git diff --color-words -U0"
From: Markus Heidelberg @ 2009-10-28 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Markus Heidelberg
In-Reply-To: <1256732672-11817-1-git-send-email-markus.heidelberg@web.de>
Colored word diff without context lines firstly printed all the hunk
headers among each other and then printed the diff.
Because the word diff cannot be calculated before the end of the diff
(added/removed lines) hunk, it was calculated directly before first line
of context after the diff. But this didn't work if there was no context.
In this case the diff wasn't printed in fn_out_consume(), but entirely
in free_diff_words_data(). This also led to calculate the colored diff
from the whole diff in one swoop instead of calculating it in several
independent steps (one step per hunk).
We now calculate and print the word diff directly before the next hunk
header. The word diff of the last hunk is still printed in
free_diff_words_data().
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
diff.c | 13 +++++++++----
t/t4034-diff-words.sh | 2 +-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/diff.c b/diff.c
index 067e5a0..e95fe9b 100644
--- a/diff.c
+++ b/diff.c
@@ -785,10 +785,15 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
diff_words_append(line, len,
&ecbdata->diff_words->plus);
return;
- } else if (line[0] == ' ') {
- if (ecbdata->diff_words->minus.text.size ||
- ecbdata->diff_words->plus.text.size)
- diff_words_show(ecbdata->diff_words);
+ }
+ /*
+ * If line[0] == '@' then this prints the content of the
+ * previous hunk, necessary for 0-context.
+ */
+ if (ecbdata->diff_words->minus.text.size ||
+ ecbdata->diff_words->plus.text.size)
+ diff_words_show(ecbdata->diff_words);
+ if (line[0] == ' ') {
line++;
len--;
emit_line(ecbdata->file, plain, reset, line, len);
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 82240cf..21db6e9 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -77,7 +77,7 @@ cat > expect <<\EOF
<GREEN>aeff = aeff * ( aaa )<RESET>
EOF
-test_expect_failure 'word diff without context' '
+test_expect_success 'word diff without context' '
word_diff --color-words --unified=0
--
1.6.5.2.86.g61663
^ permalink raw reply related
* [PATCH 2/3] diff: move the handling of the hunk header after the changed lines
From: Markus Heidelberg @ 2009-10-28 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Markus Heidelberg
In-Reply-To: <1256732672-11817-1-git-send-email-markus.heidelberg@web.de>
In preparation for a special case handling of colored word diff without
context.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
diff.c | 41 +++++++++++++++++++++--------------------
1 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/diff.c b/diff.c
index b0c7e61..067e5a0 100644
--- a/diff.c
+++ b/diff.c
@@ -771,17 +771,6 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
len = 1;
}
- if (line[0] == '@') {
- len = sane_truncate_line(ecbdata, line, len);
- find_lno(line, ecbdata);
- emit_line(ecbdata->file,
- diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
- reset, line, len);
- if (line[len-1] != '\n')
- putc('\n', ecbdata->file);
- return;
- }
-
if (len < 1) {
emit_line(ecbdata->file, reset, reset, line, len);
return;
@@ -796,17 +785,18 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
diff_words_append(line, len,
&ecbdata->diff_words->plus);
return;
+ } else if (line[0] == ' ') {
+ if (ecbdata->diff_words->minus.text.size ||
+ ecbdata->diff_words->plus.text.size)
+ diff_words_show(ecbdata->diff_words);
+ line++;
+ len--;
+ emit_line(ecbdata->file, plain, reset, line, len);
+ return;
}
- if (ecbdata->diff_words->minus.text.size ||
- ecbdata->diff_words->plus.text.size)
- diff_words_show(ecbdata->diff_words);
- line++;
- len--;
- emit_line(ecbdata->file, plain, reset, line, len);
- return;
}
- if (line[0] != '+') {
+ if (line[0] == ' ' || line[0] == '-') {
const char *color =
diff_get_color(ecbdata->color_diff,
line[0] == '-' ? DIFF_FILE_OLD : DIFF_PLAIN);
@@ -814,10 +804,21 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
if (line[0] == ' ')
ecbdata->lno_in_postimage++;
emit_line(ecbdata->file, color, reset, line, len);
- } else {
+ return;
+ } else if (line[0] == '+') {
ecbdata->lno_in_postimage++;
emit_add_line(reset, ecbdata, line + 1, len - 1);
+ return;
}
+
+ /* line[0] == '@' */
+ len = sane_truncate_line(ecbdata, line, len);
+ find_lno(line, ecbdata);
+ emit_line(ecbdata->file,
+ diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
+ reset, line, len);
+ if (line[len-1] != '\n')
+ putc('\n', ecbdata->file);
}
static char *pprint_rename(const char *a, const char *b)
--
1.6.5.2.86.g61663
^ permalink raw reply related
* [PATCH 0/3] fix "git diff --color-words -U0"
From: Markus Heidelberg @ 2009-10-28 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Markus Heidelberg
The wrong output roughly is as follows:
@@ -a,b +c,d @@
@@ -e,f +g,h @@
some red, green and black text
more red, green and black text
When it should be:
@@ -a,b +c,d @@
some red, green and black text
@@ -e,f +g,h @@
more red, green and black text
Markus Heidelberg (3):
t4034-diff-words: add a test for word diff without context
diff: move the handling of the hunk header after the changed lines
diff: fix the location of hunk headers for "git diff --color-words
-U0"
diff.c | 40 +++++++++++++++++++++++-----------------
t/t4034-diff-words.sh | 20 ++++++++++++++++++++
2 files changed, 43 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH 1/3] t4034-diff-words: add a test for word diff without context
From: Markus Heidelberg @ 2009-10-28 12:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Markus Heidelberg
In-Reply-To: <1256732672-11817-1-git-send-email-markus.heidelberg@web.de>
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
t/t4034-diff-words.sh | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 4508eff..82240cf 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -68,6 +68,26 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
+<BROWN>@@ -1 +1 @@<RESET>
+<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
+<BROWN>@@ -3,0 +4,4 @@ a = b + c<RESET>
+
+<GREEN>aa = a<RESET>
+
+<GREEN>aeff = aeff * ( aaa )<RESET>
+EOF
+
+test_expect_failure 'word diff without context' '
+
+ word_diff --color-words --unified=0
+
+'
+
+cat > expect <<\EOF
+<WHITE>diff --git a/pre b/post<RESET>
+<WHITE>index 330b04f..5ed8eff 100644<RESET>
+<WHITE>--- a/pre<RESET>
+<WHITE>+++ b/post<RESET>
<BROWN>@@ -1,3 +1,7 @@<RESET>
h(4),<GREEN>hh<RESET>[44]
<RESET>
--
1.6.5.2.86.g61663
^ permalink raw reply related
* Re: how to split a hunk
From: Thomas Rast @ 2009-10-28 13:06 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091028022105.GE3938@debian.b2j>
bill lam wrote:
> There are occasions where diff of a file is
>
> - aaaa
> + bbbb
> + cccc
>
> I want to add lines bbbb and cccc as separated commits, but git-add -p
> seem cannot further split this hunk. Do I have no choice but to edit
> it by hand and commit the bbbb and then edit the file to add back the
> cccc?
There's also the 'git add -p' [e]dit feature, which pops up the patch
in an editor. There are instructions in that file, but in this case,
you can simply remove one of the additions.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] imap-send.c: fix pointer to be const
From: Michael J Gruber @ 2009-10-28 13:33 UTC (permalink / raw)
To: Vietor Liu; +Cc: Junio C Hamano, git
In-Reply-To: <1256713526.3333.0.camel@localhost.localdomain>
Vietor Liu venit, vidit, dixit 28.10.2009 08:05:
> On Tue, 2009-10-27 at 23:26 -0700, Junio C Hamano wrote:
>> Vietor Liu <vietor@vxwo.org> writes:
>>
>>> Fixes some compiler warnings:
>>> imap-send.c: In function ‘ssl_socket_connect’:
>>> warning: assignment discards qualifiers from pointer target type
>>>
>>> Signed-off-by: Vietor Liu <vietor@vxwo.org>
>>
>> I do not quite understand. This variable gets assigned the return values
>> from TLSv1_method() or SSLv23_method(), but the copy of ssl.h I have
>> declares them as:
>>
>> SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2 */
>> SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
>
> 1. openssl-devel-1.0.0-0.10
>
> const SSL_METHOD *SSLv23_method(void); /* SSLv3 but can rollback to v2
> */
> const SSL_METHOD *TLSv1_method(void); /* TLSv1.0 */
>
>
> 2. http://www.openssl.org/docs/ssl/ssl.html
>
> const SSL_METHOD *SSLv2_method(void);
>
> Constructor for the SSLv2 SSL_METHOD structure for combined
> client and server.
> const SSL_METHOD *TLSv1_method(void);
>
> Constructor for the TLSv1 SSL_METHOD structure for combined
> client and server.
>
> 3. it maybe fixes warnings for other version.
No const here with openssl 0.9.8k. I think major distros will switch to
1.0.0 with their next major release (e.g. Fedora 12 will have it by the
end of this year).
Since this is only about warnings, maybe git 1.7.0 is the right time
frame to adjust this to the upcoming standard?
Michael
^ permalink raw reply
* Re: [PATCH] commit: More generous accepting of RFC-2822 footer lines.
From: David Brown @ 2009-10-28 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, David Brown, git@vger.kernel.org
In-Reply-To: <7vk4yguh00.fsf@alter.siamese.dyndns.org>
On Wed, Oct 28, 2009 at 12:14:55AM -0700, Junio C Hamano wrote:
> When deciding to omit adding a new S-o-b, we deliberately check only the
> last S-o-b to see if it matches what we are trying to add. This is so
> that a message from you, that has my patch that was reviewed and touched
> up by you with your sign-off, i.e.
This is good to know. I'll leave the existing last-SoB test in
place then, and just use the sophisticated check for a block of
RFC2822 footers to determine if there should be a blank line.
Jeff also pointed out that I should probably also allow lines
starting with whitespace to be considered header lines.
David
^ permalink raw reply
* Re: [PATCH] bash completion: difftool accepts the same options as diff
From: Shawn O. Pearce @ 2009-10-28 14:32 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Junio C Hamano, git, David Aguilar
In-Reply-To: <1256723138-1480-1-git-send-email-markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> wrote:
> So complete refs, files after the doubledash and some diff options that
> make sense for difftool.
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Baz @ 2009-10-28 14:34 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910280520t497f1289sf374a3a501856a23@mail.gmail.com>
2009/10/28 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Tue, Oct 27, 2009 at 10:05 PM, Baz <brian.ewins@gmail.com> wrote:
>> I'm fine with this way of fixing it, but I'd make a few more changes...
>
> Feel free to make a patch-series that addresses more issues - I'm not going to.
>
Yep, I wrote one but had to leave the house before sending it. Later today.
> We make patches of one change at the time in Git. Other (related)
> usability issues becomes separate patches, preferably grouped together
> in a patch-series. This change would be one patch in such a series.
>
>>> OPTIONS_SPEC="\
>>> git-rebase [-i] [options] [--] <upstream> [<branch>]
>>
>> Use the dashless form and be more consistent with the help - and
>> mention '--root' here, it appears in the
>> help below:
>>
>> -git-rebase [-i] [options] [--] <upstream> [<branch>]
>> +git rebase [--interactive | -i] [options] [--onto <newbase>] [--]
>> <upstream> [<branch>]
>> +git rebase [--interactive | -i] [options] --onto <newbase> --root
>> [--] [<branch>]
>>
>
> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you
> mean to use the long-form instead of the short-form? I'll assume
> that's what you mean for now, since you changed "-i" to "--interactive
> | -i".
No, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a
couple of things at once.
>
> If so, I'm not 100% convinced it's a clear win: some grep'ing
> indicates that both the short and long form are both widely used, with
> short-option bein a slight favor:
> $ git grep " \[--" | grep -v " \[--\]" | wc -l
> 228
> $ git grep " \[-[^-]" | wc -l
> 243
>
> Also, the usage isn't the only documentation. I think it makes sense
> to try to keep the usage short and to the point, there's a list
> describing each option (showing the full-name) further down in the
> usage-message. And if that's not enough, there's the "git
> help"-command.
>
> If I've misunderstood you and you only want the usage-string to match
> that of the manpage, perhaps that might be a good idea. I dunno.
In the patch I've followed other uses of OPTIONS_SPEC; they're quite
verbose, covering all options, while scripts using USAGE/LONG_USAGE
tend to emit one-liners. As for calling out 'interactive', at the
other extreme its not clear to me why we mention '-i' separately from
'[options]' at all. rebase is already pretty inconsistent here, giving
short or long usage messages depending on whether you passed '-i'. But
I'll take comments on this when I submit the patch, I've no strong
feelings on it.
>
>>
>>> -git-rebase [-i] (--continue | --abort | --skip)
>>> +git-rebase [-i] [-m] (--continue | --abort | --skip)
>>
>> Again, dashless. And I'd not mention the useless -i here, the man page
>> doesn't either:
>>
>> -git-rebase [-i] (--continue | --abort | --skip)
>> +git rebase (--continue | --abort | --skip)
>>
>
> It was already there, so I didn't consider it, but I guess it makes
> sense. Besides, I aimed at not loosing any information while making it
> a bit clearer.
>
>> These two items are misplaced in the help (I think). They're not like
>> abort, continue, skip, but then, the man page doesn't group those
>> separately either.
>>
>> +no-verify override pre-rebase hook from stopping the operation
>> +root rebase all reachable commmits up to the root(s)
>>
>
> Agree.
>
>>> Actions:
>>> continue continue rebasing process
>>> abort abort rebasing process and restore original branch
>>
>> As above, remove the next two lines after your patch:
>>
>> -no-verify override pre-rebase hook from stopping the operation
>> -root rebase all reachable commmits up to the root(s)
>
> I don't follow this. Are you repeating yourself now? :)
Yes :) ... was just finishing off moving those two lines.
Cheers,
Baz
>
> --
> Erik "kusma" Faye-Lund
>
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-28 14:41 UTC (permalink / raw)
To: Baz; +Cc: Git Mailing List
In-Reply-To: <2faad3050910280734l7297c30erfb0a47b12b0bd07d@mail.gmail.com>
On Wed, Oct 28, 2009 at 3:34 PM, Baz <brian.ewins@gmail.com> wrote:
> 2009/10/28 Erik Faye-Lund <kusmabite@googlemail.com>:
>> I'm not sure I follow - aren't dashless options, uhm, dashless? Do you
>> mean to use the long-form instead of the short-form? I'll assume
>> that's what you mean for now, since you changed "-i" to "--interactive
>> | -i".
>
> No, I just meant 'git rebase' not 'git-rebase'. Sorry, I changed a
> couple of things at once.
Ah, didn't notice that one. I completely agree with you on this.
> tend to emit one-liners. As for calling out 'interactive', at the
> other extreme its not clear to me why we mention '-i' separately from
> '[options]' at all. rebase is already pretty inconsistent here, giving
> short or long usage messages depending on whether you passed '-i'. But
> I'll take comments on this when I submit the patch, I've no strong
> feelings on it.
It's a simple reason why the output is different - this is the usage
for "git rebase -i" (hence it is in git-rebase--interactive.sh). I
guess this distinction would be slightly clearer if we removed the
brackets from the usage like this:
-git-rebase [-i] [whatever]
+git-rebase -i [whatever]
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: sp/smart-http topic
From: Shawn O. Pearce @ 2009-10-28 14:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> * sp/smart-http (2009-10-14) 17 commits
> - Smart fetch over HTTP: client side
...
> What's the doneness of this series?
Not done yet. I want to respin once more before it hits next.
I've picked up a number of test related changes from Clemens
Buchacher and Tay Ray Chuan, plus some suggestions from the latter
were fixed up in the WebDAV code.
John "warthog9" Hawley and I were spending some time yesterday to
try to figure out why smart HTTP serving off kernel.org was giving
me only 300 KiB/sec during clone, but git-daemon was giving me 12
MiB/sec for the same server and repository.
Peff noticed the TCP windows for smart HTTP were ~16 KiB in size,
but with git-daemon were ~200 KiB on size. John and I are pretty
sure this is the throughput problem, but we haven't found why the
window is so much smaller under smart HTTP.
We also need proper tests for smart HTTP. I haven't had time to
write tests yet, and the ones that were proposed for t5540-http-push
aren't suitable because you have to run the test suite twice in
order to test both WebDAV and smart HTTP push for the same build.
--
Shawn.
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter @ 2009-10-28 15:02 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130910270953w6bd35ddctd471e682830b8f62@mail.gmail.com>
Don't have root access at work == no wireshark.
^ permalink raw reply
* Re: how to split a hunk
From: bill lam @ 2009-10-28 15:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200910281406.12923.trast@student.ethz.ch>
On Wed, 28 Oct 2009, Thomas Rast wrote:
> There's also the 'git add -p' [e]dit feature, which pops up the patch
> in an editor. There are instructions in that file, but in this case,
> you can simply remove one of the additions.
Thank you for pointing out the [e], incidentally after trying it, I
also noticed and tried the add -e which belongs to a similar format.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* packaging vs default pager
From: Ben Walton @ 2009-10-28 15:21 UTC (permalink / raw)
To: GIT List
[-- Attachment #1: Type: text/plain, Size: 999 bytes --]
Hi All,
I'd like to see what people think about providing a configure/Makefile
knob for overriding the default pager at build time. Currently,
things use 'less' as the fallback and rely on the path to find
it.
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which forces
users to alter their environment (PATH, GIT_PAGER, LESS, etc) or have
a local or global gitconfig before paging works as expected.
Would it be completely out of line to provide a knob so that the
fallback $pager could be set to something more specific/appropriate
during the build? [I'll do the work but not if it's an undesirable
addition.]
Alternately, are packagers recommended to simply ship a global
gitconfig that sets core.pager?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: how to split a hunk
From: bill lam @ 2009-10-28 15:26 UTC (permalink / raw)
To: Geert Bosch; +Cc: git
In-Reply-To: <21963906-785A-4D98-8AD8-A89ED914920C@adacore.com>
On Tue, 27 Oct 2009, Geert Bosch wrote:
> I like to use "git gui" for this. This allows you to pick individual
> lines to commit. I really like the "git gui" interface for staging/unstaging
> changes and making a series of commits.
Thank you suggestion. However I did not use git-gui/gitk or have tcl
installed.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-28 15:35 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20091028T160202-594@post.gmane.org>
Peter <peter.odeus <at> gmail.com> writes:
>
>
> Don't have root access at work == no wireshark.
>
>
I have tried to attach rich console output (thanks to env variable
GIT_CURL_VERBOSE=1) into a gmane-follow-up-message.
No dice.
Are there restrictions on what characters are permitted?
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Scott Chacon @ 2009-10-28 15:37 UTC (permalink / raw)
To: David Aguilar; +Cc: Charles Bailey, git list, Junio C Hamano
In-Reply-To: <20091028090022.GA90780@gmail.com>
Hey,
On Wed, Oct 28, 2009 at 2:00 AM, David Aguilar <davvid@gmail.com> wrote:
>> I'm just wondering, does this work well with unixes and Mac OS X? I
>> think it's recommended install practice to symlink p4v as p4merge on
>> *nix, but Mac OS X needs some sort of 'launchp4merge' to be called
>> IIRC, or is this something that users can just configure with
>> mergetool.p4diff.path?
>
> I just tested this on Mac OS X with the latest version of
> p4merge. It worked great.
>
> $ git config difftool.p4merge.path \
> /Applications/p4merge.app/Contents/MacOS/p4merge
>
> $ git difftool -t p4merge HEAD^
>
This is how I have it setup as well and both diff and merge work for
me. I had to do a weird thing with passing it $LOCAL twice if there
was no merge base since otherwise it does a diff tool instead of a
merge tool - the difference is based on the number of arguments, but
it seems to work pretty well. I can try it on Linux a bit later, but
I'm not sure why launchp4merge would be needed instead of setting the
path like this on a Mac - if there is no serious objection, I can
resend this with my Signed-Off-By (sorry, I forgot).
Thanks,
Scott
^ permalink raw reply
* Re: merge confusion
From: Alex Riesen @ 2009-10-28 15:43 UTC (permalink / raw)
To: Tim Mazid; +Cc: git
In-Reply-To: <26093419.post@talk.nabble.com>
On Wed, Oct 28, 2009 at 13:01, Tim Mazid <timmazid@hotmail.com> wrote:
> You can just do a 'git branch branch-to-merge COMMIT' then 'git merge
> branch-to-merge' from your feature branch. Alternatively, you could just do
> a straight 'git merge COMMIT' from your feature branch. Though I'm not sure
> of the consequences of merging a commit instead of a branch.
The only consequence is that the merge commit message (if there will be any,
fast-forward merges don't merge anything) will mention the SHA1 instead of
branch name. You can provide your own merge commit message, of course
(while merging and afterwards).
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 15:50 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <82fd2c5d0910280138r52baff98p3f4ff65e968b0d37@mail.gmail.com>
On Wed, Oct 28, 2009 at 4:38 AM, Peter Odéus <peter.odeus@gmail.com> wrote:
> * Re-using existing connection! (#0) with host proxyserver.acme.com
> * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > GET http://gitrepo.outside.com/git/gitrepo.git/objects/6b/132a9e81161e58812902d7f735a38bf5ee1583 HTTP/1.1
> Proxy-Authorization: Basic cmQva3F3Zzc2MjptYW1tYW1pYQ==
> User-Agent: git/1.6.5.2
> Host: gitrepo.outside.com
> Accept: */*
>
> * The requested URL returned error: 404
So this git object didn't exist, apparently. Can you confirm that the
object shouldn't be there? (on the server: git cat-file -p
6b132a9e81161e58812902d7f735a38bf5ee1583) Does git-fsck report
anything weird on the server repository?
> * Closing connection #0
> * Couldn't find host gitrepo.outside.com in the .netrc file, using defaults
> * About to connect() to proxyserver.acme.com port 8080
> * Trying 192.71.145.9... * connected
> * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > GET http://gitrepo.outside.com/git/gitrepo.git/objects/info/http-alternates HTTP/1.1
> User-Agent: git/1.6.5.2
> Host: gitrepo.outside.com
> Accept: */*
> Pragma: no-cache
>
> < HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires
> authorization to fulfill the request. Access to the Web Proxy service
> is denied. )
This error seems to happen because the Proxy-Authorization line was
not included in this request like it was included in prior ones.
Probably the authorization key was forgotten when the first connection
closed. If there hadn't been a 404, the connection wouldn't have
closed and this wouldn't have happened, which is presumably why you
haven't seen this problem before.
This is where my expertise ends, since I've never messed with either
libcurl or git's usage of it. I couldn't tell you if this is a
libcurl bug or a git bug. (Proxies are relatively rare nowadays, so
this code path is likely to be rarely tested.)
Hopefully someone else on the list can assist.
** WARNING: the username/password sent in the Proxy-Authorization line
is not encrypted and you've posted a trace of it to a public mailing
list. You need to change your password immediately. **
Good luck,
Avery
^ permalink raw reply
* Re: git svn branch tracking + ignore paths
From: Avery Pennarun @ 2009-10-28 16:00 UTC (permalink / raw)
To: Lachlan Deck; +Cc: git list
In-Reply-To: <19979334-07EB-48CA-8E62-4ECC5E1FA51C@gmail.com>
On Wed, Oct 28, 2009 at 1:59 AM, Lachlan Deck <lachlan.deck@gmail.com> wrote:
> On 28/10/2009, at 4:20 PM, Avery Pennarun wrote:
>> So which are the files you don't want to import from trunk? It
>> doesn't sound like there are any... so it's getting simpler already.
>
> There are. I've currently (as a workaround) done the following within the
> main branch:
> add the following to .git/info/exclude
> .settings
> target
> .classpath
> .project
>
> The last two of these has no effect of course because .project and
> .classpath files already exist -- and thus are marked as modified. So I'm
> currently doing a git stash && git svn rebase && git svn dcommit && git
> stash pop
>
> I'm also wanting to exclude 'lib' folders from trunk (as these are not
> needed).
The problem is that as your branch diverges from what you *actually*
want to commit, it becomes exponentially more complicated to figure
out what you *do* want to commit.
Note that if you're planning to share your git project with other
people anyway, then you have an additional problem: you're using git
svn rebase, which is almost useless for sharing with other people
(other than through svn, of course), for the same reason any git
rebase is.
One option you have is to maintain two branches:
1. (git-svn) The git-svn trunk, which contains only stuff you want upstream
2. (master) Your live branch, which contains everything from (1) plus
your local customizations.
When you want to fetch from svn, you do this:
git checkout master
git svn fetch git-svn
git merge git-svn
When you want to push to svn, you do this:
git checkout git-svn
git merge --squash --no-commit master
(now undo your local customizations)
git commit
git svn dcommit
git checkout master
git merge git-svn
Note that master never gets rebased, only merged. If you can write a
simple script for "undo your local customizations" - such as reverting
a particular commit, for example - then you can put the above in a
shell script and it should work fine most of the time.
Good luck.
Avery
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-28 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130910280850t5b4baa91p90b31b4c1c467e94@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
>
> On Wed, Oct 28, 2009 at 4:38 AM, Peter Odéus <peter.odeus <at> gmail.com>
wrote:
> > * Re-using existing connection! (#0) with host proxyserver.acme.com
> > * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > > GET
>
http://gitrepo.outside.com/git/gitrepo.git/objects/6b/132a9e81161e58812902d7f735
a38bf5ee1583 HTTP/1.1
> > Proxy-Authorization: Basic cmQva3F3Zzc2MjptYW1tYW1pYQ==
> > User-Agent: git/1.6.5.2
> > Host: gitrepo.outside.com
> > Accept: */*
> >
> > * The requested URL returned error: 404
>
> So this git object didn't exist, apparently. Can you confirm that the
> object shouldn't be there? (on the server: git cat-file -p
> 6b132a9e81161e58812902d7f735a38bf5ee1583) Does git-fsck report
> anything weird on the server repository?
>
> > * Closing connection #0
> > * Couldn't find host gitrepo.outside.com in the .netrc file, using defaults
> > * About to connect() to proxyserver.acme.com port 8080
> > * Trying 192.71.145.9... * connected
> > * Connected to proxyserver.acme.com (192.71.145.9) port 8080
> > > GET http://gitrepo.outside.com/git/gitrepo.git/objects/info/http-
alternates HTTP/1.1
> > User-Agent: git/1.6.5.2
> > Host: gitrepo.outside.com
> > Accept: */*
> > Pragma: no-cache
> >
> > < HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires
> > authorization to fulfill the request. Access to the Web Proxy service
> > is denied. )
>
> This error seems to happen because the Proxy-Authorization line was
> not included in this request like it was included in prior ones.
> Probably the authorization key was forgotten when the first connection
> closed. If there hadn't been a 404, the connection wouldn't have
> closed and this wouldn't have happened, which is presumably why you
> haven't seen this problem before.
>
> This is where my expertise ends, since I've never messed with either
> libcurl or git's usage of it. I couldn't tell you if this is a
> libcurl bug or a git bug. (Proxies are relatively rare nowadays, so
> this code path is likely to be rarely tested.)
>
> Hopefully someone else on the list can assist.
>
> ** WARNING: the username/password sent in the Proxy-Authorization line
> is not encrypted and you've posted a trace of it to a public mailing
> list. You need to change your password immediately. **
>
> Good luck,
>
> Avery
>
If you wouldn't have posted the base64-encoded password it would have never hit
the gmane list ;-)
Don't worry about it, because I tried to submit the console output myself all
day. But to no avail.
Is it enough to replace greater-than-signs to something else, btw?
Anyway. Behind these corporate walls, the proxy is a reality to deal with, so
hopefully someone else can bring us closer to a solutiuon.
Thanks for your input.
:D
/Peter
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 16:35 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <loom.20091028T170227-957@post.gmane.org>
On Wed, Oct 28, 2009 at 12:10 PM, Peter Odéus <peter.odeus@gmail.com> wrote:
> Avery Pennarun <apenwarr <at> gmail.com> writes:
> If you wouldn't have posted the base64-encoded password it would have never hit
> the gmane list ;-)
Sorry about that. The To: line indicated that the message had been
sent to the list, so I didn't realize that your copy was rejected. I
have no idea what made gmane reject it for you (or whether my own copy
was rejected, for that matter :)).
Avery
^ permalink raw reply
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-28 16:48 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <loom.20091028T170227-957@post.gmane.org>
On Wed, Oct 28, 2009 at 12:10 PM, Peter Odéus <peter.odeus@gmail.com> wrote:
> Anyway. Behind these corporate walls, the proxy is a reality to deal with, so
> hopefully someone else can bring us closer to a solutiuon.
I was just looking at the source and it seems all the curl-related
stuff is isolated in git/http.c, and is pretty easy to understand.
Since I have no way to reproduce your problem, I won't attempt to look
into it myself. But if you look for "proxy" (and especially
CURLOPT_PROXY) in that file, you might find something.
Specifically, I would suggest resetting the CURLOPT_PROXY setting
before each URL request (eg. in new_http_object_request).
Hope this helps.
Avery
^ 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