[PATCH 1/2] gitk: Highlight current search hit in orange

[Stefan Haller]

When searching for text in the diff, and there are multiple occurrences
of the search string, the current one is highlighted in orange, and the
other ones in yellow. This makes it much easier to understand what happens
when you then click the Search button or hit Ctrl-S repeatedly.

Signed-off-by: Stefan Haller 
---
 gitk | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/gitk b/gitk
index 16832a9..e2c0f1c 100755
--- a/gitk
+++ b/gitk
@@ -2361,6 +2361,7 @@ proc makewindow {} {
 $ctext tag conf mresult -font textfontbold
 $ctext tag conf msep -font textfontbold
 $ctext tag conf found -back yellow
+$ctext tag conf currentsearchhit -back orange
 
 .pwbottom add .bleft
 if {!$use_ttk} {
@@ -2523,6 +2524,7 @@ proc makewindow {} {
 bind $cflist $ctxbut {pop_flist_menu %W %X %Y %x %y}
 bind $ctext $ctxbut {pop_diff_menu %W %X %Y %x %y}
 bind $ctext  {focus %W}
+bind $ctext <> rehighlight_search_results
 
 set maincursor [. cget -cursor]
 set textcursor [$ctext cget -cursor]
@@ -8039,7 +8041,6 @@ proc settabs {{firstab {}}} {
 proc incrsearch {name ix op} {
 global ctext searchstring searchdirn
 
-$ctext tag remove found 1.0 end
 if {[catch {$ctext index anchor}]} {
# no anchor set, use start of selection, or of visible area
set sel [$ctext tag ranges sel]
@@ -8058,8 +8059,8 @@ proc incrsearch {name ix op} {
suppress_highlighting_file_for_current_scrollpos
highlightfile_for_scrollpos $here
}
-   searchmarkvisible 1
 }
+rehighlight_search_results
 }
 
 proc dosearch {} {
@@ -8087,6 +8088,7 @@ proc dosearch {} {
set mend "$match + $mlen c"
$ctext tag add sel $match $mend
$ctext mark unset anchor
+   rehighlight_search_results
 }
 }
 
@@ -8115,18 +8117,36 @@ proc dosearchback {} {
set mend "$match + $ml c"
$ctext tag add sel $match $mend
$ctext mark unset anchor
+   rehighlight_search_results
+}
+}
+
+proc rehighlight_search_results {} {
+global ctext searchstring
+
+$ctext tag remove found 1.0 end
+$ctext tag remove currentsearchhit 1.0 end
+
+if {$searchstring ne {}} {
+   searchmarkvisible 1
 }
 }
 
 proc searchmark {first last} {
 global ctext searchstring
 
+set sel [$ctext tag ranges sel]
+
 set mend $first.0
 while {1} {
set match [$ctext search -count mlen -- $searchstring $mend $last.end]
if {$match eq {}} break
set mend "$match + $mlen c"
-   $ctext tag add found $match $mend
+   if {$sel ne {} && [$ctext compare $match == [lindex $sel 0]]} {
+   $ctext tag add currentsearchhit $match $mend
+   } else {
+   $ctext tag add found $match $mend
+   }
 }
 }
 
-- 
1.7.12.1.399.gae20e0d

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

[PATCH 2/2] gitk: Highlight first search result immediately on incremental search

[Stefan Haller]

When typing in the "Search" field, select the current search result (so
that it gets highlighted in orange). This makes it easier to understand
what will happen if you then type Ctrl-S.

Signed-off-by: Stefan Haller 
---
 gitk | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
index e2c0f1c..39c40de 100755
--- a/gitk
+++ b/gitk
@@ -8053,9 +8053,12 @@ proc incrsearch {name ix op} {
}
 }
 if {$searchstring ne {}} {
-   set here [$ctext search $searchdirn -- $searchstring anchor]
+   set here [$ctext search -count mlen $searchdirn -- $searchstring anchor]
if {$here ne {}} {
$ctext see $here
+   set mend "$here + $mlen c"
+   $ctext tag remove sel 1.0 end
+   $ctext tag add sel $here $mend
suppress_highlighting_file_for_current_scrollpos
highlightfile_for_scrollpos $here
}
-- 
1.7.12.1.399.gae20e0d

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

[PATCH 0/2] gitk: Better highlighting of search results

[Stefan Haller]

Here's something that has been bugging me for a long time: when using
the incremental search feature, it's hard to tell what happens when
clicking the Search button (or type Ctrl-S) repeatedly. It does have
the concept of a "current" search hit, and Ctrl-S advances to the next
one; however, you can't see it because all search hits are highlighted
in the same way (yellow). So when there are multiple hits visible on
the current page, it will at some point scroll down to reveal more
hits, but it's impossible to predict when this will happen.

To improve this, we highlight the current search in orange and the
other ones in yellow (like Chrome does it when you search on a Web
page).

Needs to go on top of the recent "Synchronize highlighting in file view
when scrolling diff" patch, v3.

[PATCH 1/2] gitk: Highlight current search hit in orange
[PATCH 2/2] gitk: Highlight first search result immediately on incremental 
search
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] gitk: Work around empty back and forward images when buttons are disabled

[Stefan Haller]

On Mac, the back and forward buttons show an empty rectange instead of
a grayed-out arrow when they are disabled. The reason is a Tk bug on Mac
that causes disabled images not to draw correctly (not to draw at all,
that is); see
.

To work around this, we explicitly provide gray images for the disabled
state; I think this looks better than the default stipple effect that you
get on Windows as well, but that may be a matter of taste.

Signed-off-by: Stefan Haller 
---
 gitk | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/gitk b/gitk
index d93bd99..e7723db 100755
--- a/gitk
+++ b/gitk
@@ -2161,7 +2161,7 @@ proc makewindow {} {
 trace add variable sha1string write sha1change
 pack $sha1entry -side left -pady 2
 
-image create bitmap bm-left -data {
+set bm_left_data {
#define left_width 16
#define left_height 16
static unsigned char left_bits[] = {
@@ -2169,7 +2169,7 @@ proc makewindow {} {
0x0e, 0x00, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0x7f, 0x0e, 0x00, 0x1c, 0x00,
0x38, 0x00, 0x70, 0x00, 0xe0, 0x00, 0xc0, 0x01};
 }
-image create bitmap bm-right -data {
+set bm_right_data {
#define right_width 16
#define right_height 16
static unsigned char right_bits[] = {
@@ -2177,11 +2177,16 @@ proc makewindow {} {
0x00, 0x38, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0x7f, 0x00, 0x38, 0x00, 0x1c,
0x00, 0x0e, 0x00, 0x07, 0x80, 0x03, 0xc0, 0x01};
 }
-${NS}::button .tf.bar.leftbut -image bm-left -command goback \
-   -state disabled -width 26
+image create bitmap bm-left -data $bm_left_data
+image create bitmap bm-left-gray -data $bm_left_data -foreground "#999"
+image create bitmap bm-right -data $bm_right_data
+image create bitmap bm-right-gray -data $bm_right_data -foreground "#999"
+
+${NS}::button .tf.bar.leftbut -image [list bm-left disabled bm-left-gray] \
+   -command goback -state disabled -width 26
 pack .tf.bar.leftbut -side left -fill y
-${NS}::button .tf.bar.rightbut -image bm-right -command goforw \
-   -state disabled -width 26
+${NS}::button .tf.bar.rightbut -image [list bm-right disabled 
bm-right-gray] \
+   -command goforw -state disabled -width 26
 pack .tf.bar.rightbut -side left -fill y
 
 ${NS}::label .tf.bar.rowlabel -text [mc "Row"]
-- 
1.7.12.1.399.gae20e0d

--
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: The GitTogether

[Michael J Gruber]

Sebastian Schuberth venit, vidit, dixit 21.09.2012 16:33:
> On Fri, Sep 21, 2012 at 4:19 PM, Scott Chacon 
> wrote:
> 
 I'm also very much interested in attending a gathering Berlin,
 though preferably not in the first week of October. As I'm a
 local, I could probably also help with finding a location if
 necessary.
>> 
>> If you would like, I would love to get you in contact with the 
>> GitHubber in Berlin who is helping to secure a venue there so you
>> can help.
> 
> Sure, feel free to forward him / her my email address. I'm surprised 
> to hear that you had so much trouble finding / booking a location.
> For example, I would have expected one of the many co-working
> locations in Berlin [1] to be a good fit.
> 
> [1] http://www.coworking.de/regions/1-berlin

Also, there are many academic institutions, and at least some might be
happy to host an event like this (I'm thinking especially of the Zuse
institute). I had offered to help with hooking up with them  several
weeks ago already. So, it's really just a matter of communication.

Michael
--
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 are the ways CRLF files can make it into the repository?

[Konstantin Khomoutov]

On Fri, Sep 21, 2012 at 01:02:11PM -0600, Joshua Jensen wrote:

> We've been running with core.autocrlf = input (some people with
> core.autocrlf = true).  However, there are some text files in the
> repository that are CRLF, and I am at a loss to explain how they go
> here.
> 
> We understand that if core.autocrlf=false, this could happen.  While
> I admit there is a remote possibility this did occur, I'm not
> convinced our people were smart enough with Git 1.5 years ago to
> make this configuration change.
> 
> There are no .gitattributes settings for these source code files.
> 
> Are there other ways CRLF files could sneak into the repository?
Is there any chance Git considered them binary for some reason and hence
did not apply its EOL-conversion logic at all?

--
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: How do I run tests under Valgrind?

[Stefano Lattarini]

On 09/21/2012 10:49 PM, Jeff King wrote:
>
> Oh. It sounds like setting $SHELL to zsh is really the problem, then. If
> it is not Bourne-compatible when called as "zsh", then it really should
> be called in a way that turns on compatibility mode (bash will do this
> when called as "sh", but you can also do it with "bash --posix").
>
AFAIK, if Zsh is called as "sh", it too will run in Bourne compatibility
mode; not sure how to force this compatibility from the command line though
(albeit I'd guess there is some way to do so).

As further reference, here is the trick autoconf uses to (try to) put Zsh
in Bourne compatibility mode after it has been invoked:

if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
   emulate sh
   NULLCMD=:
   # Pre-4.2 versions of Zsh do word splitting on ${1+"$@"}, which
   # is contrary to our usage.  Disable this feature.
   alias -g '${1+"$@"}'='"$@"'
   setopt NO_GLOB_SUBST
fi

You might think to use something like that in 't/test-lib.sh' (and other "shell
libraries" of the testsuite), but sadly that would not be enough; this excerpt
from the Automake suite shows why:

   # If Zsh is not started directly in POSIX-compatibility mode, it has some
   # incompatibilities in the handling of $0 that conflict with our usage;
   # i.e., $0 inside a file sourced with the '.' builtin is temporarily set
   # to the name of the sourced file.  Work around that.  The apparently
   # useless 'eval' here is needed by at least dash 0.5.2, to prevent it
   # from bailing out with an error like "Syntax error: Bad substitution".
   # Note that a bug in some versions of Zsh prevents us from resetting $0
   # in a sourced script, so the use of $argv0.  For more info see:
   #  
   eval 'argv0=${functrace[-1]%:*}' && test -f "$argv0" || {
 echo "Cannot determine the path of running test script." >&2
 echo "Your Zsh (version $ZSH_VERSION) is probably too old." >&2
 exit 99
   }

Since I see that '$0' is used in (at least) 't/perf/perf-lib.sh' and
't/test-lib.sh', you'd need to copy the snippet above (or write an
equivalent one) in those files, and change them to use '$argv0' instead
of '$0' in few (but not all) places.  Not sure whether it's worth it
though -- given that you seems to have solved the issue already with a
simpler change, I'd say it's not.

Regards,
  Stefano
--
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] graph: avoid infinite loop in graph_show_commit()

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

The loop can be triggered with "git diff-tree --graph commit" where
the commit is a non-merge. It goes like this

 - graph_show_commit
 - graph_next_line
 - graph_output_padding_line

The last function quits because graph->commit is NULL, but
graph_next_line() does not return "shown", so the loop in
graph_show_commit keeps going.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Corner case. Nobody sane would do that. But still worth plugging.

 graph.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/graph.c b/graph.c
index e864fe2..1735b26 100644
--- a/graph.c
+++ b/graph.c
@@ -1224,7 +1224,7 @@ void graph_show_commit(struct git_graph *graph)
struct strbuf msgbuf = STRBUF_INIT;
int shown_commit_line = 0;
 
-   if (!graph)
+   if (!graph || !graph->commit)
return;
 
while (!shown_commit_line) {
-- 
1.7.12.1.389.gc2218b5

--
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: Quickly searching for a note

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 22.09.2012 01:51:
> Jeff King  writes:
> 
>> I think people have provided sane techniques for doing this with a
>> pipeline. But there is really no reason not to have --grep-notes, just
>> as we have --grep.  It's simply that nobody has implemented it yet (and
>> nobody is working on it as far as I know). It would actually be a fairly
>> simple feature to add if somebody wanted to get their feet wet with git.
> 
> I agree that the implementation will be simple once you figure out
> what the sensible semantics and external interfaces are. The latter
> is not that simple and certainly not something for newbies to solve
> on their own.  That is why I didn't mention it.
> 
> But now you brought it up, here are a few thinking-points as a
> starter:
> 
>  - Wouldn't it be more intuitive to just let the normal "--grep" to
>also hit what "--show-notes" would add to the output?  Does it
>really add value to the end user experience to add a separate
>"--grep-notes=P4[0-9]*" option, even though it would give you
>more flexibility?
> 
>Not having thought things through thorouly, I still answer this
>question both ways myself and what the right user experience
>should look like.
> 
>  - Do we want to be limited to one notes tree?  Would it make sense
>to show notes from the usual commit notes but use different notes
>tree for the sole purpose of restricting visibility?  If we
>wanted to allow that for people who want flexibility, but still
>want to use only one and the same by default, what should the
>command line options look like?
> 
>  - Would it be common to say "I want commits with _any_ notes from
>this notes tree"?  Having to say "--grep-notes=." for such a
>simple task, if it is common, feels a bit clunky.
> 

On my mental scratch pad (yeah, that's where the bald spots are) I have
the following more general idea to enhance the revision parser:

--limit-run=

Re: How do I run tests under Valgrind?

[Jeff King]

On Sat, Sep 22, 2012 at 03:03:58PM +0200, Stefano Lattarini wrote:

> On 09/21/2012 10:49 PM, Jeff King wrote:
> >
> > Oh. It sounds like setting $SHELL to zsh is really the problem, then. If
> > it is not Bourne-compatible when called as "zsh", then it really should
> > be called in a way that turns on compatibility mode (bash will do this
> > when called as "sh", but you can also do it with "bash --posix").
> >
> AFAIK, if Zsh is called as "sh", it too will run in Bourne compatibility
> mode; not sure how to force this compatibility from the command line though
> (albeit I'd guess there is some way to do so).
> [...]

Thanks for digging. I think this case, though, is that we were simply
using the wrong variable ($SHELL instead of $SHELL_PATH). Your
workarounds would help if somebody put zsh into $SHELL_PATH, but
fundamentally that is not a sane thing to be doing, so I think we can
just consider doing so user error and not bother working around it.

-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: The GitTogether

[Enrico Weigelt]

Hi,

> Also, there are many academic institutions, and at least some might
> be happy to host an event like this (I'm thinking especially of the Zuse
> institute). I had offered to help with hooking up with them  several
> weeks ago already. So, it's really just a matter of communication.

Yep. Another option could be Fraunhofer (we've got connections there),
or maybe Office-2.0 or Tempelhof Airport.

I've already triggered our business guys, they're quite interested.


cu
-- 
Mit freundlichen Grüßen / Kind regards 

Enrico Weigelt 
VNC - Virtual Network Consult GmbH 
Head Of Development 

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

enrico.weig...@vnc.biz; www.vnc.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: How do I run tests under Valgrind?

[Stefano Lattarini]

On 09/22/2012 07:47 PM, Jeff King wrote:
> On Sat, Sep 22, 2012 at 03:03:58PM +0200, Stefano Lattarini wrote:
> 
>> On 09/21/2012 10:49 PM, Jeff King wrote:
>>>
>>> Oh. It sounds like setting $SHELL to zsh is really the problem, then. If
>>> it is not Bourne-compatible when called as "zsh", then it really should
>>> be called in a way that turns on compatibility mode (bash will do this
>>> when called as "sh", but you can also do it with "bash --posix").
>>>
>> AFAIK, if Zsh is called as "sh", it too will run in Bourne compatibility
>> mode; not sure how to force this compatibility from the command line though
>> (albeit I'd guess there is some way to do so).
>> [...]
> 
> Thanks for digging. I think this case, though, is that we were simply
> using the wrong variable ($SHELL instead of $SHELL_PATH). Your
> workarounds would help if somebody put zsh into $SHELL_PATH, but
> fundamentally that is not a sane thing to be doing, so I think we can
> just consider doing so user error and not bother working around it.
> 
FWIW, I agree.

Best regards,
  Stefano

--
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] t/test-lib.sh: do not trust $SHELL

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Here's a patch.
>
> -- 8< --
> From: Ramkumar Ramachandra 
> Date: Sat, 22 Sep 2012 10:25:10 +0530
> Subject: [PATCH] test-lib: do not trust $SHELL
>
> Do not trust $SHELL to be a bourne-compatible shell.  Instead, use the
> Makefile variable $SHELL_PATH.  This fixes a bug: when a test was run
> with --tee and $SHELL was set to ZSH, $PATH on line 479 was not
> getting split due to ZSH not respecting $IFS.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---

The part that this starts letting run, which the original "Re-run
the command under tee as early as possible" wanted to avoid running,
does not affect anything that would affect how we run that tee magic
(e.g. "mkdir -p test-results" will still create it directly inside
the directory the test script was started in), so I think this patch
is safe _for now_.

However, it forces people who need to update earlier parts of this
script to be extra careful; it has been true before the patch, and
the patch makes it even more so.

I am not opposed to queuing this as an interim solution, but I
wonder if we can get rid of that double-launch altogether.

Instead of re-launching the script with its output piped to "tee",
can't we do the same by redirecting our standard output to the file
in the file, and spawn a "tail -f" that reads from the file and
outputs to our original output?  Something along the lines of:

mkdir -p test-results
tee_base=test-results/$(basename "$0" .sh)

# empty the file and start "tail -f" on it ...
: >"$tee_base.out"
( tail -f "$tee_base.out" ) &
tee_pid=$!
trap 'kill $tee_pid; exit' 0 1 2 3
# ... and then redirect our output to it
exec >"$tee_base.out"

and wrap it in a shell helper function that is called from where the
parsing of the command line arguments for "--tee" happens, and don't
forget to kill $tee_pid when we exit.

Hrm?
--
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: Quickly searching for a note

[Junio C Hamano]

Michael J Gruber  writes:

> On my mental scratch pad (yeah, that's where the bald spots are) I have
> the following more general idea to enhance the revision parser:
>
> --limit-run=

Re: How do I run tests under Valgrind?

[Junio C Hamano]

Jeff King  writes:

> On Sat, Sep 22, 2012 at 03:03:58PM +0200, Stefano Lattarini wrote:
>
>> On 09/21/2012 10:49 PM, Jeff King wrote:
>> >
>> > Oh. It sounds like setting $SHELL to zsh is really the problem, then. If
>> > it is not Bourne-compatible when called as "zsh", then it really should
>> > be called in a way that turns on compatibility mode (bash will do this
>> > when called as "sh", but you can also do it with "bash --posix").
>> >
>> AFAIK, if Zsh is called as "sh", it too will run in Bourne compatibility
>> mode; not sure how to force this compatibility from the command line though
>> (albeit I'd guess there is some way to do so).
>> [...]
>
> Thanks for digging. I think this case, though, is that we were simply
> using the wrong variable ($SHELL instead of $SHELL_PATH). Your
> workarounds would help if somebody put zsh into $SHELL_PATH, but
> fundamentally that is not a sane thing to be doing, so I think we can
> just consider doing so user error and not bother working around it.

Yeah, 100% agreed with your assessment, including the part thanking
Stefano.

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

Re: submodule: if $command was not matched, don't parse other args

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> When we try to execute 'git submodule' with an invalid subcommand, we
> get an error like the following:
>
> $ git submodule show
> error: pathspec 'show' did not match any file(s) known to git.
> Did you forget to 'git add'?
>
> The cause of the problem: since $command is not matched, it is set to
> "status", and "show" is treated as an argument to "status".  Change
> this so that usage information is printed when an invalid subcommand
> is tried.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  This breaks test 41 in t7400-submodule-bash -- does the test cover a
>  real-world usecase?

You know how to ask "shortlog --since=18.months --no-merges" to find
people to list on "Cc:" line to ask that question, no?

> diff --git a/git-submodule.sh b/git-submodule.sh
> index a7e933e..dfec45d 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -1108,7 +1108,15 @@ do
>  done
>
>  # No command word defaults to "status"
> -test -n "$command" || command=status
> +if test -z "$command"
> +then
> +if test $# = 0
> +then
> + command=status
> +else
> + usage
> +fi
> +fi

I personally feel "no command means this default" is a mistake for
"git submodule", even if there is no pathspec or other arguments,
but I am not a heavy user of submodules, so others should discuss
this.

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

Re: git clone over http with basic auth bug?

[Paul J R]

Indeed, thats correct, i should have tried a newer version really before 
i posted cause i do pull the main git repo and it would have been 
relatively easy.


Newer version did indeed fix the problem.

It hadnt occured to me that git-http-backend behaves differently to the 
"dumb" http protocol on read (though that was from reading the git 
source so i obviously missed what was going on there). Ultimately im 
writing a little webapp that wraps around git-http-backend for some git 
repository management and on reads i've been just "acting like 
webserver" but on writes i throw off to git-http-backend. But seeing it 
do authenticated reads properly via git-http-backend im going to change 
how it functions, cause that does work with older clients.


Thanks!

On 22/09/12 15:09, Jeff King wrote:

On Sat, Sep 22, 2012 at 09:37:38AM +1000, Paul J R wrote:


Im not sure if this is a bug, or just "as implemented". But when
cloning from a repo sitting on a web site that uses basic auth, the
git client appears to forget its authentication info and ignores the
401's the server is sending back. It appears to initially login and
get refs and HEAD ok, but after that it never authenticates again.
Using a .netrc file this will work (or a url of the form
http://user:pass@host though http://user@host wont), but i'm curious
if theres a way of doing this without having to expose the password
in some way?

Im using git 1.7.9.5 and when i clone i get the following:
[...]

 From your logs, it looks like you are using the "dumb" http protocol
(wherein the server does not have to understand git at all). In this
protocol, we end up making multiple simultaneous requests for objects
with different curl handles. We had a bug where not all handles are told
about the credential (but it doesn't always happen; it depends on the
exact pattern of requests).

This was fixed by dfa1725 (fix http auth with multiple curl handles,
2012-04-10), which is in git v1.7.10.2 and higher.

Can you try upgrading to see if that fixes your problem?

-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

Message from 'git-rebase'; German translation

[Sascha Cunz]

As I know how hard translations can be, esp. with that much technical terms 
inside, I'm usually expecting _not_ to yield the same result when translating 
a software's translation back to English.

However, git-rebase just threw these two sentences at me (And though i know 
their meaning, i couldn't get the meaning from the message, it gave). Both are 
in context of starting a rebase while one is already in progress.

first is:

Original:
... and I wonder if you are in the middle of another rebase.

German git translation:
... und es wäre verwunderlich, wenn ein Neuaufbau bereits im Gange ist.

And a re-translation back to English from my understanding as native German 
speaker:
... and it would be astonishing (=i'd be surprised), if a rebase was already 
in progress.

And second:

Original:
I am stopping in case you still have something valuable there.

German git translation:
Es wird angehalten, falls bereits etwas Nützliches vorhanden ist.

I wanted to point out that "etwas Nützliches" is more "something useful" that 
"something valuable". But the more I thought about it, the more it started to 
confuse me (even the original text) - and now I feel like I don't understand 
the meaning of the last sentence at all; neither in English nor in the German 
translation:
After removing the directory with all rebase-information inside it, WHERE 
should something valuable still be left over? Is it referring to my working 
tree?

So, for completeness, the full English message:

It seems that there is already a rebase-merge directory, and
I wonder if you are in the middle of another rebase.  If that is the
case, please try
   git rebase (--continue | --abort | --skip)
If that is not the case, please
rm -fr "/work/lg2/src/.git/rebase-merge"
and run me again.  I am stopping in case you still have something
valuable there.

Sascha

--
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: [RFC] Questions for "Git User's Survey 2011"

[Jakub Narębski]

On Wed, Sep 19, 2012 at 7:35 PM, Felipe Contreras
 wrote:
> Hi,
>
> On Wed, Sep 14, 2011 at 7:39 PM, Jakub Narebski  wrote:
>
>> P.S. Would you be interested in running the next survey?
>
> I haven't seen any news regarding the 2012 survey. I'm interested in
> running the survey this time, but I would like to know what that
> entails :)
>
> I think the surveys should continue.

I have created short (well, at least shorter than previous ones)
"Git User's Survey 2012" on Survs.com.  The test channel is

  https://www.survs.com/survey/J87I3PDBU4

Note that all answers in this channel would be deleted.


I was thinking about running this survey for about three weeks, from
24 September to 14 October 2012.  The current premium unlimited plan,
a gift from Survs.com admins, is valid till 26 October.  I don't know if it
would be prolonged; it usually was.

As to what is involved in running survey: if we want and would be able to
use Survs.com, one should register there, and I can add them to "git"
account as a member with admin rights.

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