* Re: Problem with bisect
From: Sean @ 2007-08-06 18:12 UTC (permalink / raw)
To: Larry Finger; +Cc: git
In-Reply-To: <46B623D6.7070809@lwfinger.net>
On Sun, 05 Aug 2007 14:24:06 -0500
Larry Finger <larry.finger@lwfinger.net> wrote:
> Sean wrote:
> > On Sun, 05 Aug 2007 11:02:21 -0500
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> >> I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and
> >> v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's
> >> wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we
> >> obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before
> >> bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this
> >> code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom
> >> is all the way to v2.6.16, which I think is the origin of the git process.
> >>
> >> Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by
> >> arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has
> >> been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the
> >> bug doesn't show on my machine.
> >>
> The git repo is git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git.
>
> The commands were:
>
> git bisect start
> git bisect bad
> git bisect good v2.6.22
>
> I'm using git version 1.4.4.2.g04509
The directory "drivers/net/wireless/bcm43xx-mac80211" is only introduced in
commit v2.6.23-rc1-1621-gd05daff. It didn't exist in v2.6.22.
You can see this with the command:
$ git log -- drivers/net/wireless/bcm43xx-mac80211
Where the last listed commit is d05daff. So of course there will be many
bisection points back to v2.6.22 where that directory just doesn't exist.
A bit of digging with Git shows this history for most of the files in
that directory:
renamed in v2.6.23-rc1-1621 as bcm43xx-mac80211
renamed in v2.6.21-rc1-809 as mac80211
renamed in v2.6.17-rc2-357 as d80211/bcm43xx
Imported in v2.6.16-1725 as bcm43xx-d80211
HTH,
Sean
^ permalink raw reply
* Re: way to automatically add untracked files?
From: David Kastrup @ 2007-08-06 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Miles Bader, git
In-Reply-To: <7vwsw9capl.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> We recently talked about this on the mailing list and decided that
>> git-add shouldn't remove files that have disappeared, as doing so
>> might break most user's expections of what git-add does.
>> ...
>> "git commit -a" will remove disappeared files. It has for quite
>> some time.
>
> It obviously is not the time to do this as I have already said
> that I won't look at anything but fixes and documentation
> updates until 1.5.3, but I am not opposed to have "git add -a $paths"
> which would do something like "git add $paths && git add -u $paths".
I'm all for it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Problem with bisect
From: Larry Finger @ 2007-08-06 18:37 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <20070806141233.3d8a43cc.seanlkml@sympatico.ca>
Sean wrote:
>
> The directory "drivers/net/wireless/bcm43xx-mac80211" is only introduced in
> commit v2.6.23-rc1-1621-gd05daff. It didn't exist in v2.6.22.
>
> You can see this with the command:
>
> $ git log -- drivers/net/wireless/bcm43xx-mac80211
>
> Where the last listed commit is d05daff. So of course there will be many
> bisection points back to v2.6.22 where that directory just doesn't exist.
> A bit of digging with Git shows this history for most of the files in
> that directory:
>
> renamed in v2.6.23-rc1-1621 as bcm43xx-mac80211
> renamed in v2.6.21-rc1-809 as mac80211
> renamed in v2.6.17-rc2-357 as d80211/bcm43xx
> Imported in v2.6.16-1725 as bcm43xx-d80211
Thanks for the response. Obviously the difficulties were due to the structure of the tree. This
chunk of code has had a varied history.
Larry
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Eran Tromer @ 2007-08-06 18:42 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070805144632.GB999MdfPADPa@greensroom.kotnet.org>
On 2007-08-05 10:46, Sven Verdoolaege wrote:
>> $ git checkout experimental-death-ray
>> $ git submodules update
>> (return a week later, woozy from the vacation.)
>> $ git checkout master
>
> Here, it'll warn that your submodule isn't up-to-date.
>
>> (hack hack hack)
>> $ git commit -a -m "fixed typos"
>
> And if you run "git status" first, it'll tell you that the submodule
> (still) isn't up-to-date.
>
>> $ git push
>> (Oops. You've just accidentally committed the wrong submodule heads.)
>
> You always have to be careful when doing "git commit -a".
Exactly. You now have to be very careful, whereas previously
$ git checkout master && vi foo && git commit -a -m "fixed typos"
was perfectly safe.
Worse yet, it could also be a script making similar assumptions. For
example, consider the tree filter in git-filter-branch. It used to be
fine, but will now corrupt the rewritten trees when submodules are
involved. Here's the relevant code from git-filter-branch.sh:
-----------------------------------------------------------------
while read commit parents; do
...
git read-tree -i -m $commit
...
git checkout-index -f -u -a ||
die "Could not checkout the index"
...
eval "$filter_tree" < /dev/null ||
die "tree filter failed: $filter_tree"
git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git update-index --add --replace --remove
...
sh -c "$filter_commit" "git commit-tree" \
$(git write-tree) $parentstr < ../message > ../map/$commit
done <../revs
-----------------------------------------------------------------
>> Another approach is for pull, checkout etc. to automatically update the
>> submodule' head ref, but no more.
>
> Then everything, including "git submodule update", would assume
> that the submodule is up-to-date.
With that approach, "git submodule update" would fetch the submodule's
head commit (which could be missing), and then check it against the
submodule's index (and maybe its work tree).
Eran
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-06 19:03 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
In-Reply-To: <46B76B8C.9050905@tromer.org>
On Mon, Aug 06, 2007 at 02:42:20PM -0400, Eran Tromer wrote:
> On 2007-08-05 10:46, Sven Verdoolaege wrote:
> > You always have to be careful when doing "git commit -a".
>
> Exactly. You now have to be very careful, whereas previously
> $ git checkout master && vi foo && git commit -a -m "fixed typos"
> was perfectly safe.
I don't see the difference. If you forgot you changed something
(be it a submodule or a file) you will commit something you
didn't plan to commit.
bash-3.00$ git init; touch a b c; git add .; git commit -m 1
Initialized empty Git repository in .git/
Created initial commit 4e6da45: 1
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
create mode 100644 b
create mode 100644 c
bash-3.00$ git checkout -b branch
Switched to a new branch "branch"
bash-3.00$ echo "foo" > a; git add a; git commit -m 2
Created commit fe87123: 2
1 files changed, 1 insertions(+), 0 deletions(-)
bash-3.00$ echo "bar" > c
bash-3.00$ git checkout master && echo "test" > b && git commit -a -m 'change b'
M c
Switched to branch "master"
Created commit 657c5b1: change b
2 files changed, 2 insertions(+), 0 deletions(-)
> >> Another approach is for pull, checkout etc. to automatically update the
> >> submodule' head ref, but no more.
> >
> > Then everything, including "git submodule update", would assume
> > that the submodule is up-to-date.
>
> With that approach, "git submodule update" would fetch the submodule's
> head commit (which could be missing), and then check it against the
> submodule's index (and maybe its work tree).
And how is anyone supposed to figure out what HEAD the submodule's
index and working tree correspond to?
I can only hope that "git submodule update" would never blindly assume
that the submodule is clean and so the user would have to manually
sync the HEAD and the working tree.
skimo
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: Robin Rosenberg @ 2007-08-06 19:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Johannes Schindelin, Steffen Prohaska, gitster, git
In-Reply-To: <20070806035119.GB30269@fieldses.org>
måndag 06 augusti 2007 skrev J. Bruce Fields:
> On Mon, Aug 06, 2007 at 01:26:21AM +0100, Johannes Schindelin wrote:
> > On Sun, 5 Aug 2007, J. Bruce Fields wrote:
> > > A big warning would be out of place in what is for now just an isolated
> > > sentence in two different places. But I agree with you that this would
> > > be worth mentioning in any eventual full-fledged git-gui tutorial.
> >
> > Unfortunately, I am really wasted by this weekend's efforts to bring
> > msysgit.git along... could you be so kind as to cut&paste the relevant
> > section in a reply to me, so I do not have to search for myself?
>
> Sure; appended. This isn't that different from Steffen's proposal.
>
> > I would not normally ask for such a favour; it is relatively easy to go on
> > a search with Git, but I do have only 8 hours of sleep in the last 60
> > hours under my saddle...
>
> Hm. On the other hand, maybe we should just be refusing to feed your
> addiction till you get some sleep.
>
> I wanna keep this short for now, so if we really think we shouldn't
> mention of the hunk-selection thing without a warning, I'd rather just
> omit mention of it, and go for something like: "You can also use
> gitlink:git-gui[1] to create commits and view changes in the index and
> working tree", and drop the second hunk. Whatever.
Who reads manuals for GUI's? Rougly nobody, unless the user needs the gui
badly AND the GUI sucks badly. Manuals for GUI's are mostly tick-in-the-box
documentation (which is the probably reason most GUI documentation suck too).
Uncommon/dangerous features should generally be harder to find, but can you
can also use the common pattern of popping a dialog explaining the dangers
and forcing the user to click away the box. Of course there should be a
checkbox in the dialog "[X] Void warranty and don't bother me with this
question anymore."
Nevertheless the dangers should be explained somewhere, maybe in the git user
manual. I believe most people will learn from experience.
-- robin
^ permalink raw reply
* Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-06 19:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, Steffen Prohaska, gitster, git
In-Reply-To: <200708062136.50462.robin.rosenberg.lists@dewire.com>
On Mon, Aug 06, 2007 at 09:36:49PM +0200, Robin Rosenberg wrote:
> Who reads manuals for GUI's? Rougly nobody, unless the user needs the gui
> badly AND the GUI sucks badly. Manuals for GUI's are mostly tick-in-the-box
> documentation (which is the probably reason most GUI documentation suck too).
I tend to agree. But the goal for now isn't to provide complete
documentation, it's just to briefly point out the existence of this tool
and what it does.
I haven't used it myself other than just to experiment a bit, but my
impression from the people involved is that they still consider it a bit
young, but that they think it's useful and that they'd benefit from more
people trying it out.
--b.
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthieu Moy @ 2007-08-06 20:05 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqdkbq59.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Ack, ack, ack. The current default behavior is plainly unusable. For
> example, I've rsynced -a a tree including .git, and suddenly git-diff
> goes out of kilter. And stops doing so when running git-status
> once.
Unfortunately, the patch solves the "large and irrelevant output" of
git-diff, but not the performance problem (see the rest of the thread,
I failed to convince Junio that updating the index was a performance
improvement while keeping the same user semantics).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] check_repository_format_version(): run git_default_config() again
From: Junio C Hamano @ 2007-08-06 20:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <7vbqdkcxy3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Sorry, I do not understand this patch from the commit log
> description.
>
> In the old days in 1.5.2 before either implementation of
> work-tree stuff, this function never called git_default_config()
> and presumably "git log" worked as expected for Brian. Why is
> this call needed _here_, not in some of the callers?
Sorry scratch that. v1.5.2 did not even have core.pager.
I see git_config(git_default_config) is called from
setup_git_directory_gently() in the version that introduced
core.pager. Curiously enough it does the config twice, once
where no GIT_DIR is set and it sets inside_work_tree, and
another by calling git_config(git_setup_config) -- big thanks
for sorting this mess out.
I however have a mild suspicion that this has to be done much
earlier.
For example, "git -p log" would first call handle_options(),
which calls the setup_pager() logic, and then we call
handle_internal_command() which calls setup_git_directory() that
eventually leads to the callchain of finding the .git directory
and .git/config file to be used. In that case, when we make the
call to setup_pager() from handle_options(), we haven't even
figured out if there is a configuration file, let alone reading
from it.
We could work this around by having the "we need config -- where
is it" logic in setup_pager(), but if we later have new options
like -p that affects the way how git wrapper itself behaves
based on the configuration, we would need the same "early config
read" logic to support it.
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-06 20:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, David Kastrup
In-Reply-To: <vpqr6mgwhsf.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Unfortunately, the patch solves the "large and irrelevant output" of
> git-diff, but not the performance problem (see the rest of the thread,
> I failed to convince Junio that updating the index was a performance
> improvement while keeping the same user semantics).
That's what update-index --refresh (or status if you insist) are
for, and the coalmine canary you are so dead set to kill are
helping you realize the need for running.
^ permalink raw reply
* [PATCH] send-email: teach sanitize_address to do rfc2047 quoting
From: Uwe Kleine-König @ 2007-08-06 20:34 UTC (permalink / raw)
To: Git Mailing List; +Cc: Uwe Kleine-König, Jakub Narebski
In-Reply-To: <20070806083341.GA6625@informatik.uni-freiburg.de>
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
I removed the _rfc822 suffix from the function name as it now does more
than rfc822 quoting.
I dug through rfc822 to do the double quoting right. Only if that is not
possible rfc2047 quoting is applied.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.com>
---
As Jakub critizied now the "easiest" quoting is done.
git-send-email.perl | 39 +++++++++++++++++++++++++++++----------
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index f43f92f..39e433b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -289,7 +289,7 @@ sub expand_aliases {
}
@to = expand_aliases(@to);
-@to = (map { sanitize_address_rfc822($_) } @to);
+@to = (map { sanitize_address($_) } @to);
@initial_cc = expand_aliases(@initial_cc);
@bcclist = expand_aliases(@bcclist);
@@ -459,22 +459,41 @@ sub unquote_rfc2047 {
return "$_";
}
-# If an address contains a . in the name portion, the name must be quoted.
-sub sanitize_address_rfc822
+# use the simplest quoting being able to handle the recipient
+sub sanitize_address
{
my ($recipient) = @_;
- my ($recipient_name) = ($recipient =~ /^(.*?)\s+</);
- if ($recipient_name && $recipient_name =~ /\./ && $recipient_name !~ /^".*"$/) {
- my ($name, $addr) = ($recipient =~ /^(.*?)(\s+<.*)/);
- $recipient = "\"$name\"$addr";
+ my ($recipient_name, $recipient_addr) = ($recipient =~ /^(.*?)\s*(<.*)/);
+
+ if (not $recipient_name) {
+ return "$recipient";
+ }
+
+ # if recipient_name is already quoted, do nothing
+ if ($recipient_name =~ /^(".*"|=\?utf-8\?q\?.*\?=)$/) {
+ return $recipient;
+ }
+
+ # rfc2047 is needed if a non-ascii char is included
+ if ($recipient_name =~ /[^[:ascii:]]/) {
+ $recipient_name =~ s/([^-a-zA-Z0-9!*+\/])/sprintf("=%02X", ord($1))/eg;
+ $recipient_name =~ s/(.*)/=\?utf-8\?q\?$1\?=/;
}
- return $recipient;
+
+ # double quotes are needed if specials or CTLs are included
+ elsif ($recipient_name =~ /[][()<>@,;:\\".\000-\037\177]/) {
+ $recipient_name =~ s/(["\\\r])/\\$1/;
+ $recipient_name = "\"$recipient_name\"";
+ }
+
+ return "$recipient_name $recipient_addr";
+
}
sub send_message
{
my @recipients = unique_email_list(@to);
- @cc = (map { sanitize_address_rfc822($_) } @cc);
+ @cc = (map { sanitize_address($_) } @cc);
my $to = join (",\n\t", @recipients);
@recipients = unique_email_list(@recipients,@cc,@bcclist);
@recipients = (map { extract_valid_address($_) } @recipients);
@@ -489,7 +508,7 @@ sub send_message
if ($cc ne '') {
$ccline = "\nCc: $cc";
}
- $from = sanitize_address_rfc822($from);
+ $from = sanitize_address($from);
make_message_id();
my $header = "From: $from
--
1.5.3.rc3.13.g7ab3
^ permalink raw reply related
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Dmitry Kakurin @ 2007-08-06 21:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708061134380.14781@racer.site>
On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> long time (mainly because its maintainer is on holiday). In the meantime,
> set_git_dir() is already there!
I didn't know that.
> BTW your patch was white-space mangled.
I'll be sending patches as attachments from now on.
- Dmitry
^ permalink raw reply
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Dmitry Kakurin @ 2007-08-06 21:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708061134380.14781@racer.site>
On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I had more problems than I thought with setting up a fork of mingw.git.
> It seems that the relative alternates path to mingw.git is followed, but
> not that one from mingw.git to git.git. So I could upload, but not fetch.
Does it mean that fork of a fork does not work on repo.or.cz?
- Dmitry
^ permalink raw reply
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Johannes Schindelin @ 2007-08-06 21:56 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950708061455v459182cei3fb6b3b518d4b176@mail.gmail.com>
Hi,
On Mon, 6 Aug 2007, Dmitry Kakurin wrote:
> On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > I had more problems than I thought with setting up a fork of mingw.git.
> > It seems that the relative alternates path to mingw.git is followed, but
> > not that one from mingw.git to git.git. So I could upload, but not fetch.
>
> Does it mean that fork of a fork does not work on repo.or.cz?
Yes, at the moment it does not work. Therefore I set up
git/mingw4msysgit.git, for the time being.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add support for an info version of the user manual
From: Jakub Narebski @ 2007-08-06 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <86ir7tc5xk.fsf@lola.quinscape.zz>
[Cc: David Kastrup <dak@gnu.org>, git@vger.kernel.org]
David Kastrup wrote:
> These patches use docbook2x in order to create an info version of the
> git user manual.
[...]
> ---
> Documentation/Makefile | 28 ++++++++++++++++++++++++++++
> Makefile | 6 ++++++
> 2 files changed, 34 insertions(+), 0 deletions(-)
[...]
First, a note on patch: please use $(AWK) instead of 'awk', just in case.
It would be nice to add a paragraph about build requirements for info
version of Git User's Manual in the INSTALL file.
In the future we would probably want configure.ac to support --with-info or
something like that to install documentation in info format (it does
support --infodir), perhaps with awk autodetection and docbook2x
autodetection.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: Jakub Narebski @ 2007-08-06 15:44 UTC (permalink / raw)
To: git
In-Reply-To: <f96cks$e26$1@sea.gmane.org>
[Cc: Asger Ottar Alstrup <asger@ottaralstrup.dk>, git@vger.kernel.org]
Could you Cc: me (jnareb@gmail.com)? TIA.
Asger Ottar Alstrup wrote:
> Jakub Narebski wrote:
>> I don't quite understand: what would be the question? Note that survey is
>> meant to help git community notice what needs improvements.
>
> Maybe include a question about hosting?
>
> Do you use, or have a need for, a git hosting service?
>
> [ ] No
> [ ] Yes, an open source hosting service
> [ ] Yes, a hosting service for commercial projects
First, I think 65 questions is quite many, and I'd rather not add new
questions to the survey. Besides, git hosting service belongs to area of
git auxillary; we don't have any other questions about miscelaneus git
tools, or wishes for git support in tools (like bugtracker or hosting
service).
Second, the question is a bit ambiguous: is "No" mean "no need for git
hosting service, or not using git hosting service?
BTW. there are a few free OSS git hosting services, http://repo.or.cz
I think the most prominent: see http://git.or.cz/gitwiki/GitProjects
Third, the survey is (among others) meant to help git commuinity develop git
to be better. This question is not about this.
So, I think I wont be ading this queation, unless somebody convinces me...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Dmitry Kakurin @ 2007-08-06 22:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0708062255420.14781@racer.site>
On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Does it mean that fork of a fork does not work on repo.or.cz?
>
> Yes, at the moment it does not work. Therefore I set up
> git/mingw4msysgit.git, for the time being.
That's too bad.
I was thinking about adopting distributed dev model for MinGW port of Git:
we all would fork off mingw.git on repo.or.cz and then we would pull
from each other instead of exchanging patches thru e-mail.
Personally I don't like email patch exchange process.
Can this problem on repo.or.cs be fixed? Did Petr reply?
- Dmitry
^ permalink raw reply
* [PATCH] (Really) Fix install-doc-quick target
From: Mark Levedahl @ 2007-08-06 22:43 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Git Mailing List
Cc: Ren Scharfe, Mark Levedahl
In-Reply-To: <7vmyx6fohv.fsf_-_@assigned-by-dhcp.cox.net>
Commit 00d8c51 caused git-ls-tree to be invoked from a directory where
GIT_DIR cannot be found and without that variable being set.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
Documentation/install-doc-quick.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
index 07d227f..a0164fb 100755
--- a/Documentation/install-doc-quick.sh
+++ b/Documentation/install-doc-quick.sh
@@ -25,7 +25,7 @@ git checkout-index -a -f --prefix="$mandir"/
if test -n "$GZ"; then
cd "$mandir"
- for i in `git ls-tree -r --name-only $head`
+ for i in `git --git-dir="$GIT_DIR" ls-tree -r --name-only $head`
do
gzip < $i > $i.gz && rm $i
done
--
1.5.3.rc4.5.g4f0b5
^ permalink raw reply related
* [PATCH] gitk - enable selected patch text on Windows
From: Mark Levedahl @ 2007-08-06 22:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Mark Levedahl
On windows, mouse input follows the keyboard focus, so to allow selecting
text from the patch canvas we must not shift focus back to the top level.
This change has no negative impact on X, so we don't explicitly test
for Win32 on this change. This provides similar selection capability
as already available using X-Windows.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index f74ce51..08ff5df 100755
--- a/gitk
+++ b/gitk
@@ -955,8 +955,8 @@ proc bindkey {ev script} {
# set the focus back to the toplevel for any click outside
# the entry widgets
proc click {w} {
- global entries
- foreach e $entries {
+ global ctext entries
+ foreach e [concat $entries $ctext] {
if {$w == $e} return
}
focus .
--
1.5.3.rc4.5.g4f0b5
^ permalink raw reply related
* [PATCH] gitk - Handle MouseWheel events on Windows
From: Mark Levedahl @ 2007-08-06 22:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Mark Levedahl
In-Reply-To: <1186440352826-git-send-email-mdl123@verizon.net>
Windows, unlike X-Windows, sends mousewheel events by default to the
window that has keyboard focus and uses the MouseWheel event to do so.
The window to be scrolled must be able to take focus, but gitk's panels
are disabled so cannot take focus. For all these reasons, a different
design is needed to use the mousewheel on Windows. The approach here is
to bind the mousewheel events to the top level window and redirect them
based upon the current mouse position.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
---
gitk | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 08ff5df..f6fca9b 100755
--- a/gitk
+++ b/gitk
@@ -823,8 +823,13 @@ proc makewindow {} {
pack .ctop -fill both -expand 1
bindall <1> {selcanvline %W %x %y}
#bindall <B1-Motion> {selcanvline %W %x %y}
- bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
- bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ if {[tk windowingsystem] == "win32"} {
+ bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
+ bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
+ } else {
+ bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
+ bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ }
bindall <2> "canvscan mark %W %x %y"
bindall <B2-Motion> "canvscan dragto %W %x %y"
bindkey <Home> selfirstline
@@ -918,6 +923,30 @@ proc makewindow {} {
-command rmbranch
}
+# Windows sends all mouse wheel events to the current focused window, not the one where
+# the mouse hovers, so instead bind mouse to the top level window and redirect
+proc windows_mousewheel_redirector {W X Y D} {
+ global canv canv2 canv3
+ set w [winfo containing -displayof $W $X $Y]
+ if {$w ne ""} {
+ if {$w == $canv || $w == $canv2 || $w == $canv3} {
+ if {$D < 0} {
+ allcanvs yview scroll 5 units
+ } else {
+ allcanvs yview scroll -5 units
+ }
+ } else {
+ catch {
+ if {$D < 0} {
+ $w yview scroll 5 units
+ } else {
+ $w yview scroll -5 units
+ }
+ }
+ }
+ }
+}
+
# mouse-2 makes all windows scan vertically, but only the one
# the cursor is in scans horizontally
proc canvscan {op w x y} {
--
1.5.3.rc4.5.g4f0b5
^ permalink raw reply related
* Re: [MinGW PATCH] git clone was failing with 'invalid object name HEAD' if ran from cmd.exe directly
From: Johannes Schindelin @ 2007-08-06 22:48 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: git
In-Reply-To: <a1bbc6950708061532t45fb0cf4w716971260b0640ae@mail.gmail.com>
Hi,
On Mon, 6 Aug 2007, Dmitry Kakurin wrote:
> On 8/6/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > Does it mean that fork of a fork does not work on repo.or.cz?
> >
> > Yes, at the moment it does not work. Therefore I set up
> > git/mingw4msysgit.git, for the time being.
>
> That's too bad. I was thinking about adopting distributed dev model for
> MinGW port of Git: we all would fork off mingw.git on repo.or.cz and
> then we would pull from each other instead of exchanging patches thru
> e-mail. Personally I don't like email patch exchange process.
We can still do that. Just set up a fork of _git.git_, and initialise it
with mingw4msysgit.git.
> Can this problem on repo.or.cs be fixed? Did Petr reply?
I think it can. But Pasky seems to be extraordinarily busy these days.
So no, I got no reply besides a message on IRC that he'll try to do
something about the situation tonight.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] (Really) Fix install-doc-quick target
From: Johannes Schindelin @ 2007-08-06 22:50 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List, Ren Scharfe
In-Reply-To: <11864401942772-git-send-email-mdl123@verizon.net>
Hi,
On Mon, 6 Aug 2007, Mark Levedahl wrote:
> - for i in `git ls-tree -r --name-only $head`
> + for i in `git --git-dir="$GIT_DIR" ls-tree -r --name-only $head`
This awfully looks like hiding a bug. It should _never_ be necessary to
say '--git-dir="$GIT_DIR"'.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] (Really) Fix install-doc-quick target
From: Junio C Hamano @ 2007-08-06 23:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mark Levedahl, Git Mailing List, Ren Scharfe
In-Reply-To: <Pine.LNX.4.64.0708062349460.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 6 Aug 2007, Mark Levedahl wrote:
>
>> - for i in `git ls-tree -r --name-only $head`
>> + for i in `git --git-dir="$GIT_DIR" ls-tree -r --name-only $head`
>
> This awfully looks like hiding a bug. It should _never_ be necessary to
> say '--git-dir="$GIT_DIR"'.
Yes. And 00d8c51 obviously "works for me", so there is
something different between what Mark and I are doing. I cannot
tell what it is.
^ permalink raw reply
* Re: [PATCH] check_repository_format_version(): run git_default_config() again
From: Junio C Hamano @ 2007-08-06 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <7vsl6wbe9e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> I see git_config(git_default_config) is called ... big thanks
> for sorting this mess out.
>
> I however have a mild suspicion that this has to be done much
> earlier.
> ...
> We could work this around by having the "we need config -- where
> is it" logic in setup_pager(), but if we later have new options
> like -p that affects the way how git wrapper itself behaves
> based on the configuration, we would need the same "early config
> read" logic to support it.
Ok, how about this as an interim solution?
This is a minimum change in the sense that it restores the old
behaviour of not even reading config in setup_git_directory(),
but have the core.pager honored when we know it matters.
---
| 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
--git a/pager.c b/pager.c
index 3bfed02..8bac9d9 100644
--- a/pager.c
+++ b/pager.c
@@ -31,8 +31,11 @@ void setup_pager(void)
if (!isatty(1))
return;
- if (!pager)
+ if (!pager) {
+ if (!pager_program)
+ git_config(git_default_config);
pager = pager_program;
+ }
if (!pager)
pager = getenv("PAGER");
if (!pager)
^ permalink raw reply related
* Re: [PATCH] git-am: initialize variable $resume on startup
From: Junio C Hamano @ 2007-08-06 23:16 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070806141530.10422.qmail@8bd9c2a0b9ecab.315fe32.mid.smarden.org>
Thanks.
^ 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