* Re: Correction for post-receive-email
From: Andreas Ericsson @ 2007-10-05 8:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Eric Mertens
In-Reply-To: <200710050913.58835.andyparkins@gmail.com>
Andy Parkins wrote:
> On Friday 2007 October 05, Eric Mertens wrote:
>
>> I noticed that my mutt wasn't correctly detecting the signature block
>> on the end of the automated emails I was receiving from the script in
>> contrib. I've made this trivial change in my local copy of the script,
>> but I figured that if I was going to be modifying the source code I
>> should share my changes.
>
> That change has been in my pending queue for a while. It's technically
> correct, but I've never submitted it. The reason I haven't is that it adds
> trailing whitespace.
>
> Perhaps one of the shell gurus can offer a nicer way of having a trailing
> space be output in a heredoc that doesn't add a trailing space in the source
> script?
>
space=' '
cat << EOF
--$space
EOF
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 8:52 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>>
>>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
>>>>> Am I wrong?
>>>> About it being a majority, yes, I suspect so.
>>>>
>>> Maybe in the next survey we should include question "do you usually do
>>> 'git commit' or 'git commit -a'" :-)
>> Not meaning to discourage you, but it is a known fact that Linus does "git
>> commit" without "-a" quite often.
>>
>> And if that were not bad enough for your plan, I myself omit "-a"
>> regularly. So you would get a veto from me, too.
>
> So you are used to do something like (please correct me if I'm wrong):
> - modify A
> - modify B
> - modify C
> - modify D
> - modify E
>
> $ git A B E
This isn't really a valid command. I'm not sure where you got it from.
> $ git add A B E (A, B and E are now in the staging area)
> $ git commit -m "I just modified A,B and E"
I do something like that, except that for full-file commits I'd rather
say
git commit -s A B E
I never pass -m to git commit. It's too easy to get into habit of being
sloppy with historic documentation that way.
> $ git C D
Again not a valid command, but...
> $ git add C D (C and D are now in the staging area)
> $ git commit -m "I just modified C and D"
>
See above :)
There's also the times when I hack on some feature and find some small
bug/easy-to-write-feature, so I make the change for that other thing,
swap to a different branch and do 'git commit -s --interactive' to
just break out that small fix.
Or if I have to add some logic to some other function in a file I've
modified for other purposes and want it to be two separate commits,
I just make the change and then run 'git commit --interactive' to
make it two separate commits.
I just don't do 'git commit -a' for the same reason I don't do
'git commit -m', really. It tends to be habit-forming, and bisect
has saved my arse enough times for me to *want* my changes to be
small and isolated. Debugging a 5-line patch is so much more pleasant
than debugging a 30k-lines one that spans over several different files.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Pierre Habouzit @ 2007-10-05 8:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <Pine.LNX.4.64.0710050930030.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Fri, Oct 05, 2007 at 08:30:45AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 5 Oct 2007, Pierre Habouzit wrote:
>
> > When crlf_to_git or ident_to_git are called "in place", the buffer
> > already is big enough and should not be resized (as it could make the
> > buffer address change, hence invalidate the `src' pointers !).
>
> I wonder why we resize at all if the buffer is big enough to begin with.
strbuf_grow takes care of that itself but indeed you make me see that
my patch is wrong. if buf->len > len then len - buf->len is err a bit
big.
I'll roll better ones.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-05 8:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nguyen Thai Ngoc Duy, Wincent Colaiuta, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710042209410.4174@racer.site>
On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
> > > > Am I wrong?
> > >
> > > About it being a majority, yes, I suspect so.
> > >
> >
> > Maybe in the next survey we should include question "do you usually do
> > 'git commit' or 'git commit -a'" :-)
>
> Not meaning to discourage you, but it is a known fact that Linus does "git
> commit" without "-a" quite often.
>
> And if that were not bad enough for your plan, I myself omit "-a"
> regularly. So you would get a veto from me, too.
So you are used to do something like (please correct me if I'm wrong):
- modify A
- modify B
- modify C
- modify D
- modify E
$ git A B E
$ git add A B E (A, B and E are now in the staging area)
$ git commit -m "I just modified A,B and E"
$ git C D
$ git add C D (C and D are now in the staging area)
$ git commit -m "I just modified C and D"
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Johannes Schindelin @ 2007-10-05 8:30 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005082026.GE19879@artemis.corp>
Hi,
On Fri, 5 Oct 2007, Pierre Habouzit wrote:
> When crlf_to_git or ident_to_git are called "in place", the buffer
> already is big enough and should not be resized (as it could make the
> buffer address change, hence invalidate the `src' pointers !).
I wonder why we resize at all if the buffer is big enough to begin with.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix memory leak in apply_filter.
From: Pierre Habouzit @ 2007-10-05 8:29 UTC (permalink / raw)
To: Junio C Hamano, Bernt Hansen; +Cc: git
In-Reply-To: <20071005082026.GE19879@artemis.corp>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
While we're at it... Here is a stupid memory leak in apply_filter.
On top of the previous commit.
The same, repost, unsigned doh.
convert.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 4664197..d5c197f 100644
--- a/convert.c
+++ b/convert.c
@@ -293,10 +293,9 @@ static int apply_filter(const char *path, const char *src, size_t len,
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
--
1.5.3.4.208.gdcc67-dirty
^ permalink raw reply related
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Johannes Schindelin @ 2007-10-05 8:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steven Grimm, git
In-Reply-To: <4705EFF2.9090506@op5.se>
Hi,
On Fri, 5 Oct 2007, Andreas Ericsson wrote:
> Steven Grimm wrote:
> > git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> > leaves old commits dangling. Since dcommit is already unsafe to run
> > concurrently with other git commands, no additional risk is introduced
> > by making it prune those old objects as needed.
> >
> > Signed-off-by: Steven Grimm <koreth@midwinter.com>
> > ---
> >
> > This is in response to a colleague who complained that, after I
> > installed the latest git release, he was getting lots of "too many
> > unreachable loose objects" errors from the new "git gc --auto" run.
> > Those objects turned out to be dangling commits from a year's worth of
> > git-svn usage, since every git-svn commit will abandon at least one
> > existing commit in order to rewrite it with the svn version data.
> >
> > git-svn.perl | 6 ++++++
> > 1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 777e436..be62ee1 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -441,6 +441,12 @@ sub cmd_dcommit {
> > }
> > command_noisy(@finish, $gs->refname);
> > $last_rev = $cmt_rev;
> > +
> > + # rebase will have made the just-committed revisions
> > + # unreachable; over time that can build up lots of
> > + # loose objects in the repo. prune is unsafe to run
> > + # concurrently but so is dcommit.
> > + command_noisy(qw/gc --auto --prune/);
> > }
> > }
> > }
>
> I'd be surprised if this would ever prune anything, as git doesn't throw
> out objects reachable by reflog (or, I assume, any of the objects
> reachable from objects reachable from reflog).
It will so, in due time. Reflogs have an expiry date, and will be culled
by git gc --auto. So if you dcommit often (which I do), the objects will
be pruned, eventually.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix memory leak in apply_filter.
From: Pierre Habouzit @ 2007-10-05 8:27 UTC (permalink / raw)
To: Junio C Hamano, Bernt Hansen; +Cc: git
In-Reply-To: <20071005082026.GE19879@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
While we're at it... Here is a stupid memory leak in apply_filter.
On top of the previous commit.
convert.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/convert.c b/convert.c
index 4664197..d5c197f 100644
--- a/convert.c
+++ b/convert.c
@@ -293,10 +293,9 @@ static int apply_filter(const char *path, const char *src, size_t len,
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
--
1.5.3.4.208.gdcc67-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Peter Baumann @ 2007-10-05 8:21 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071005001528.GA13029@midwinter.com>
On Thu, Oct 04, 2007 at 05:15:28PM -0700, Steven Grimm wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
>
I don't like the automatic prune. What if someone has other objects in
there which shouldn't be pruned? Making git svn dcommit doing the prune
would be at least suprising, because how is one supposed to know that
doing a commit into svn will prune all your precious objects?
Sure, I can unterstand from where you are coming from, but I'd prefere
if this could be specified on a case by case basis, e.g. from the
cmdline or as a config option.
-Peter
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
> --
> 1.5.3.4.203.gcc61a
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Fix in-place editing in crlf_to_git and ident_to_git.
From: Pierre Habouzit @ 2007-10-05 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bernt Hansen
In-Reply-To: <87wsu2sad0.fsf@gollum.intra.norang.ca>
When crlf_to_git or ident_to_git are called "in place", the buffer already
is big enough and should not be resized (as it could make the buffer address
change, hence invalidate the `src' pointers !).
Also fix the growth length at the same time: we want to replace the buffer
content (not append) in those functions as they are filters.
Thanks to Bernt Hansen for the bug report.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This patch is done on top of master, as strbuf's have been merged.
This is a major issue.
convert.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/convert.c b/convert.c
index 0d5e909..4664197 100644
--- a/convert.c
+++ b/convert.c
@@ -110,7 +110,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (src != buf->buf)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
@@ -281,12 +283,12 @@ static int apply_filter(const char *path, const char *src, size_t len,
ret = 0;
}
if (close(pipe_feed[0])) {
- ret = error("read from external filter %s failed", cmd);
+ error("read from external filter %s failed", cmd);
ret = 0;
}
status = finish_command(&child_process);
if (status) {
- ret = error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", cmd, -status);
ret = 0;
}
@@ -422,7 +424,9 @@ static int ident_to_git(const char *path, const char *src, size_t len,
if (!ident || !count_ident(src, len))
return 0;
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (src != buf->buf)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
for (;;) {
dollar = memchr(src, '$', len);
--
1.5.3.4.207.gc79d4-dirty
^ permalink raw reply related
* Re: Correction for post-receive-email
From: Andy Parkins @ 2007-10-05 8:13 UTC (permalink / raw)
To: git; +Cc: Eric Mertens
In-Reply-To: <449c8cfc0710050014j9bbf057ka108ee27dea49a89@mail.gmail.com>
On Friday 2007 October 05, Eric Mertens wrote:
> I noticed that my mutt wasn't correctly detecting the signature block
> on the end of the automated emails I was receiving from the script in
> contrib. I've made this trivial change in my local copy of the script,
> but I figured that if I was going to be modifying the source code I
> should share my changes.
That change has been in my pending queue for a while. It's technically
correct, but I've never submitted it. The reason I haven't is that it adds
trailing whitespace.
Perhaps one of the shell gurus can offer a nicer way of having a trailing
space be output in a heredoc that doesn't add a trailing space in the source
script?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Andreas Ericsson @ 2007-10-05 8:04 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <20071005001528.GA13029@midwinter.com>
Steven Grimm wrote:
> git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
> leaves old commits dangling. Since dcommit is already unsafe to run
> concurrently with other git commands, no additional risk is introduced
> by making it prune those old objects as needed.
>
> Signed-off-by: Steven Grimm <koreth@midwinter.com>
> ---
>
> This is in response to a colleague who complained that, after I
> installed the latest git release, he was getting lots of "too many
> unreachable loose objects" errors from the new "git gc --auto" run.
> Those objects turned out to be dangling commits from a year's worth of
> git-svn usage, since every git-svn commit will abandon at least one
> existing commit in order to rewrite it with the svn version data.
>
> git-svn.perl | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index 777e436..be62ee1 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -441,6 +441,12 @@ sub cmd_dcommit {
> }
> command_noisy(@finish, $gs->refname);
> $last_rev = $cmt_rev;
> +
> + # rebase will have made the just-committed revisions
> + # unreachable; over time that can build up lots of
> + # loose objects in the repo. prune is unsafe to run
> + # concurrently but so is dcommit.
> + command_noisy(qw/gc --auto --prune/);
> }
> }
> }
I'd be surprised if this would ever prune anything, as git doesn't throw out
objects reachable by reflog (or, I assume, any of the objects reachable from
objects reachable from reflog).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Andreas Ericsson @ 2007-10-05 7:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Benoit SIGOURE, git
In-Reply-To: <20071005014229.GS2137@spearce.org>
Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> On 10/4/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>> On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
>>>> Note that Git is GPLv2, and it will probably stay that forever, so you
>>>> are _free_ to start a commercial support scheme for Git, but others
>>>> are free not to choose it. This question is to get to know if there is
>>>> sufficient demand for commercial Git support for it to be viable.
>>> Once again (AFAIR this was already raised during one of the previous
>>> summary) what's the link between GPLv2 and commercial support? You
>>> seem to imply that because Git won't move to GPLv3, it's a good thing
>>> for potential paid support, or something. I don't quite see how
>>> GPLvX comes into play with commercial support. I'm not a license
>>> expert though.
>> The only link between GPL and commercial support is that GPL does not
>> prohibit commercial support (like noncommercial-free licenses for example),
>> and that having commercial support doesn't mean that license would change
>> to proprietary (it cannot).
>
> Right. There has been some discussion in the past about forming
> "The Git Company".
>
> When this survey question was first posed there was some concern that
> Git might move to a commerical license of some sort and perhaps not
> be GPLvX anymore. That concern is a non-issue; the copyrights for
> Git are held by over 300 people, many of whom are kernel hackers and
> strong believers in the value of GPLv2. I'm not a kernel hacker,
> but I also believe strongly in the value of the GPLv2 license.
> You won't see me agreeing to move code I wrote to a non-GPL license
> anytime soon. Most (if not all!) of Git's authors feel the same way.
>
> There's several reasons why forming "The Git Company" might help
> the overall Git cause, and this question was a feeler to see if
> the community was interested in acquiring support through it. Many
> other open source projects seem to get some benefit from having a
> company loosely affiliated with them, not the least of which are
> things like:
>
> - some of the developers can focus more time on the project and
> still keep food on the table;
>
> - there are people focused on advertising/marketing the project
> and its benfits to potential end-users;
>
> - companies that feel warm-and-fuzzy by having a phone number they
> can call for help are more likely to want to use the project
> for critical services;
>
> - companies that want training or short-term consulting services
> know who they can contact for expertise.
>
> and the list goes on. The problem with said company is it costs
> money to keep the lights on and employees fed; money which obviously
> cannot be extorted from users through arcane licensing agreements.
Actually it can. I work for precisely such a company (although using
Nagios, cacti and syslog-ng as the base of our products rather than
git). The GPL doesn't state how one is allowed to charge money for
the products, but since larger networks with more users generate more
support calls, we also use a license payment model, where larger
customers pay more and smaller pay less.
The difference between proprietary software is that we have to trust
ur customers to *want* to pay the licenses, as it would be ridiculously
easy for them to replace our versions of the programs with the pristine
oss kind, or even with our patches, as we aren't allowed to keep them
private. However, doing so voids the support-agreement, as we don't take
support for code we haven't audited and tested. In other words, we *must*
provide first-class support and coding aid to our customers, or they
won't want to pay anymore. In practice, it all works out rather well, and
everyone gets something they want.
* I get paid to work with something I like.
* Customers get support, well-tested upgrades and nifty extensions.
* Project maintainers get patches, money, hardware and appreciation.
That last bit is important though. It's not terribly expensive for us to
buy a couple of books or a laptop and send it as a christmas gift to some
project maintainer, but doing so shows appreciation and also buys us the
attention of the developers for when we want our feature-patches accepted ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] gtksourceview2 support for gitview
From: Frederick Akalin @ 2007-10-05 7:20 UTC (permalink / raw)
To: git, gitster; +Cc: Frederick Akalin
Added support for gtksourceview2 module (pygtksourceview 1.90.x) in
gitview. Also refactored code that creates the source buffer and view.
Signed-off-by: Frederick Akalin <akalin@akalin.cx>
---
contrib/gitview/gitview | 53 +++++++++++++++++++++++++++-------------------
1 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 5931766..449ee69 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -28,11 +28,19 @@ import string
import fcntl
try:
+ import gtksourceview2
+ have_gtksourceview2 = True
+except ImportError:
+ have_gtksourceview2 = False
+
+try:
import gtksourceview
have_gtksourceview = True
except ImportError:
have_gtksourceview = False
- print "Running without gtksourceview module"
+
+if not have_gtksourceview2 and not have_gtksourceview:
+ print "Running without gtksourceview2 or gtksourceview module"
re_ident = re.compile('(author|committer) (?P<ident>.*) (?P<epoch>\d+) (?P<tz>[+-]\d{4})')
@@ -58,6 +66,26 @@ def show_date(epoch, tz):
return time.strftime("%Y-%m-%d %H:%M:%S", time.gmtime(secs))
+def get_source_buffer_and_view():
+ if have_gtksourceview2:
+ buffer = gtksourceview2.Buffer()
+ slm = gtksourceview2.LanguageManager()
+ gsl = slm.get_language("diff")
+ buffer.set_highlight_syntax(True)
+ buffer.set_language(gsl)
+ view = gtksourceview2.View(buffer)
+ elif have_gtksourceview:
+ buffer = gtksourceview.SourceBuffer()
+ slm = gtksourceview.SourceLanguagesManager()
+ gsl = slm.get_language_from_mime_type("text/x-patch")
+ buffer.set_highlight(True)
+ buffer.set_language(gsl)
+ view = gtksourceview.SourceView(buffer)
+ else:
+ buffer = gtk.TextBuffer()
+ view = gtk.TextView(buffer)
+ return (buffer, view)
+
class CellRendererGraph(gtk.GenericCellRenderer):
"""Cell renderer for directed graph.
@@ -582,17 +610,7 @@ class DiffWindow(object):
hpan.pack1(scrollwin, True, True)
scrollwin.show()
- if have_gtksourceview:
- self.buffer = gtksourceview.SourceBuffer()
- slm = gtksourceview.SourceLanguagesManager()
- gsl = slm.get_language_from_mime_type("text/x-patch")
- self.buffer.set_highlight(True)
- self.buffer.set_language(gsl)
- sourceview = gtksourceview.SourceView(self.buffer)
- else:
- self.buffer = gtk.TextBuffer()
- sourceview = gtk.TextView(self.buffer)
-
+ (self.buffer, sourceview) = get_source_buffer_and_view()
sourceview.set_editable(False)
sourceview.modify_font(pango.FontDescription("Monospace"))
@@ -956,16 +974,7 @@ class GitView(object):
vbox.pack_start(scrollwin, expand=True, fill=True)
scrollwin.show()
- if have_gtksourceview:
- self.message_buffer = gtksourceview.SourceBuffer()
- slm = gtksourceview.SourceLanguagesManager()
- gsl = slm.get_language_from_mime_type("text/x-patch")
- self.message_buffer.set_highlight(True)
- self.message_buffer.set_language(gsl)
- sourceview = gtksourceview.SourceView(self.message_buffer)
- else:
- self.message_buffer = gtk.TextBuffer()
- sourceview = gtk.TextView(self.message_buffer)
+ (self.message_buffer, sourceview) = get_source_buffer_and_view()
sourceview.set_editable(False)
sourceview.modify_font(pango.FontDescription("Monospace"))
--
1.5.3.3
^ permalink raw reply related
* Correction for post-receive-email
From: Eric Mertens @ 2007-10-05 7:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hello,
(My apologies if my incorrectly addressed subscribe message went to the list)
I noticed that my mutt wasn't correctly detecting the signature block
on the end of the automated emails I was receiving from the script in
contrib. I've made this trivial change in my local copy of the script,
but I figured that if I was going to be modifying the source code I
should share my changes.
--
Eric Mertens
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Correct-signature-block-delimiter-in-post-receive-em.patch --]
[-- Type: text/x-patch; name="0001-Correct-signature-block-delimiter-in-post-receive-em.patch", Size: 792 bytes --]
From 119f84fa6f6bb33c6fc524ab4277d38bebc10468 Mon Sep 17 00:00:00 2001
From: Eric Mertens <emertens@gmail.com>
Date: Fri, 5 Oct 2007 00:06:52 -0700
Subject: [PATCH] Correct signature block delimiter in post-receive-email by adding a trailing space
This change allows mail clients like Mutt to easily detect the signature
and is consistent with the signature block article on Wikipedia.
---
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index cbbd02f..828651a 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -198,7 +198,7 @@ generate_email_footer()
hooks/post-receive
- --
+ --
$projectdesc
EOF
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Alex Riesen @ 2007-10-05 6:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1191553750-25562-1-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain, Fri, Oct 05, 2007 05:09:10 +0200:
> If the repository got mangled by FAT capitalization rules, then a ref
> such as "HEAD" will become "head" once it is back on a non-FAT FS.
> Check for this condition in resolve_refs and in the setup code.
>
> Suggested-by: Francois Marier <francois@debian.org>
> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> ---
> This should probably help people putting their git repos on
> FAT USB sticks.
Can the people just mount FAT partitions with shortname=mixed?
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-05 6:40 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004161935.GC17487@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> The stat-information, and sha1sum are actually a cache, but they don't
>> have to be user-visible, except for speed.
>
> That's a big exception.--b.
Speed _is_ important, of course. But the user only benefits from
speed, he doesn't have to manipulate it explicitely. I may be
repeating myself, but "diff --cached" doesn't mean "diff using the
stat-cache", it means "diff using the cached _content_", which is
really unrelated from the stat-cache.
Mercurial also has fast diff (perhaps a bit slower that git, but same
order of magnitude), and has no user-visible index.
--
Matthieu
^ permalink raw reply
* Re: size_t vs "unsigned long"
From: Kyle Moffett @ 2007-10-05 6:27 UTC (permalink / raw)
To: Florian Weimer; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <877im3khj0.fsf@mid.deneb.enyo.de>
On Oct 03, 2007, at 17:36:03, Florian Weimer wrote:
> * Pierre Habouzit:
>> Well, afaict, on every linux archs I know of, unsigned longs and
>> size_t are the same.
>
> IIRC, 64-bit Windows uses 64-bit points (duh) and hence a 64-bit
> size_t, but still has got 32-bit longs. Documentation is a bit
> sparse on this matter (because you are supposed to use LONG, DWORD
> and friends anyway).
For reference, Linux is always an LP32 (long-and-pointer-are-32-bit)
or LP64 (long-and-pointer-are-64-bit) platform. On the other hand,
for crappy backwards-compat reasons, Windows is either LP32 or LLP64
(long-long-and-pointer-are-64-bit). I think most of the remaining
UNIXes fall into the LP32/LP64 category, the LLP64 platforms are
fairly rare (thankfully).
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Question about "git commit -a"
From: Miles Bader @ 2007-10-05 6:04 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200710042225.13670.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Now I cherry pick hunks together in coherent groups
>
> git add -i
Ooooohhhhh,.....
Boy I didn't know about add -i... that looks, really, really, really
useful...
Thanks,
-miles
--
Run away! Run away!
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Miles Bader @ 2007-10-05 5:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <5ACC5CA7-8314-4035-94EC-190138A25EBD@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> You're probably right that the option name is confusing, I guess
> changing it to "--index" would be a good idea, continuing to support
> "--cached" but marking it as deprecated before finally removing it at
> some point in the future.
Personally all I want is a short-option alias for --cached!
Hopefully something easily type-able (not uppercase)...
-Miles
--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him. -- Art Buchwald
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: David Tweed @ 2007-10-05 5:22 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <vpqtzp7ndn3.fsf@bauges.imag.fr>
On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It makes more sense to me.
>
> For me, a "cache" is a fast-access copy of something, that I can
> rebuild at any time. Cache should be only a matter of performance, if
> the "cache" for an application changes its functionality, it means the
> cache has been too optimistic. Git's index is not that, "git add"
> means "add this to the index", which itself means "put that in the
> list of things to commit", and not "get a copy of that to work faster
> with it".
Just to say this interpretation is also the natural interpretation I
have for the term "cached", and it confused me no end when I was first
learning about git that the index was referred to as a cache. To be
fair, git the documentation was in flux at that time and it's now
referred too as a cache in very few places now.
An example of the kind of thing I have to think carefully about even
now, Junio said in a different mail:
"--cached means work only on the "cached information in index."
If I understand correctly, the term "cached information in index" is
more correctly "stored information in index" (or perhaps more
technically "staged information in index") since there may be
information in there which isn't a cache because it's no longer
present anywhere else (ie, not in a commit yet but also changed in the
working tree).
It's not a big thing, but the usage of cached in git still quite confuses me.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Johannes Schindelin @ 2007-10-05 3:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1191553750-25562-1-git-send-email-sam.vilain@catalyst.net.nz>
Hi,
On Fri, 5 Oct 2007, Sam Vilain wrote:
> If the repository got mangled by FAT capitalization rules, then a ref
> such as "HEAD" will become "head" once it is back on a non-FAT FS.
Can we have that optionally, please? I.e. triggered by something like
"core.caseChallengedFS = true"?
Ciao,
Dscho
^ permalink raw reply
* The 3rd msysGit Herald
From: Johannes Schindelin @ 2007-10-05 3:13 UTC (permalink / raw)
To: git, msysgit
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6130 bytes --]
Good morning git land!
This hour of the tiger in Scotland is as good an occasion as any to issue
the third episode of the msysGit Herald, the not-quite-biweekly news letter
to keep you informed about msysGit, the effort to bring one of the most
powerful Source Code Management systems to the poor souls stuck with
Windows.
These are the covered topics:
Umlauts in the path name
Compiling Perl from scratch!
Including the 'html' branch as a submodule
The language wars, this time: no .NET in msysGit
Inno installer
Where is HOME?
Umlauts in the path name
========================
Another issue cropped up the other day; MSys cannot handle path names with
umlauts alright. For example, if you try to remove a checkout of git.git
(which unnecessarily contains an umlaut in a test for gitweb) with MSys'
"rm", it will fail. It will say that it removed the file "Märchen", but
the file is still there.
We will see if at some point in future, we will be able to compile MSys
from within msysGit, and maybe we will be able to fix this issue.
For now, please try to avoid spaces in the installation path of msysGit!
Compiling Perl from scratch!
============================
Somehow I lured Simon Sasburg into trying to get Perl compiling inside
msysGit. I already had compiled it, using the "official" method,
downloading dmake and stuff, and the result was a commit with a recipe
how to compile it from scratch (e887f810 in the "full" branch).
However, this was a MinGW Perl, not a MSys Perl. Remember: the main
difference (usage-wise) is that MSys has a fake "/" directory. So
wherever you install it, it will be able to find /etc/bla. And the
perl I built cannot use that, and therefore does not find essential
parts of git, making it useless for our purposes.
Simon jumped through the hoops and got some additional packages from
mingw.org installed, and was nice enough to put that into a branch
in msysgit.git: msysperl. When checking that branch out, you will
have a /perl directory with two scripts: one to download perl and
apply some patches, and another to build perl.
Including the 'html' branch as a submodule
==========================================
Steffen Prohaska, who was very interested in msysGit right from the start,
has joined the msysGit team. He realised that the help was not working,
and created a new submodule containing the html pages, along with some
patches to allow opening these pages, even when msysGit (or GitMe or
WinGit) was installed to a path containing spaces.
So all of you, seeking help in WinGit, look forward to the release 0.3
of WinGit, which will include some.
The language wars, this time: no .NET in msysGit
================================================
We realised pretty soon that some convenient parts which are present in
every Unix system are simply lacking in Windows.
It begins with the missing C compiler, which is so untrivial to set up
that there was a demand for msysGit. But it certainly does not end
there.
For example, the effort to compile Perl from scratch (see above) is
necessary so that we have the chance to compile the modules missing
for git-svn support.
In the midst of these efforts, a tool was checked in that allows you
to call an arbitrary diff viewer, by setting three environment
variables.
Of course, you could do that with a simple shell script, but it seems
some people are so uncomfortable with the shell that they have to
write a program to do the same.
The big problem with this program, though, is that it was written
using .NET 2.0.
I already had many complaints how many dependencies msysGit has, and
was actively working on reducing the size of the WinGit installer
by leaving out non-essential parts; and there was even talk about
making a WinGit installer that does not even install Perl.
So I was not happy with the situation, and moved the commits out of
our 'devel' branch into the branch 'dmitry/dotnet-gitdiff'.
In the wake of this cleanup, Steffen Prohaska proposed that all new
changes should first be committed to topic branches, and only move them
into 'devel' once another developer has seen them.
For a short time I was even thinking about asking all developers to
just fork msysgit.git, and work in their repositories, but for the
moment, it seems that we're okay with Steffen's proposal.
However, everyone who disagrees with me is (of course) free to fork
msysgit.git; repo.or.cz makes that trivial.
Inno installer
==============
Sebastian Schubert, a colleague of Steffen, was so disgusted with my
beautiful 7-Zip/Tk based installer that he decided to work on an Inno
based one.
Now, we already have a script to make an installer using NSIS (see the
"nsis-installer" branch of msysgit.git), but my biggest concern was
always to avoid installing other software than msysGit to build the
installers. And as far as I can tell, NSIS is not really small.
Sebastian has promised that Inno would be small enough, so I guess
we'll just wait and see...
If it finds the unilateral love of the msysGit team members, version
0.3 of the WinGit installer will already be based on Sebastian's work.
Where is HOME?
==============
While working on the Inno setup, Sebastian suggested installing an
Explorer extension so that you can "Start Git Shell here" in the
Explorer. Apparently a component of Inno makes it easy to add such a
small Explorer extension.
Unless you do a "cd $HOME" in /etc/profile, which we do. So, when
calling the shell (which has to be a login shell) we want to stay
where we are, but we do not (this was requested in Issue 51 in our
issue tracker).
In the following discussions, it appeared that not everybody is
happy that Windows, Cygwin and MSys all have different home
directories.
I proposed changing the HOME in MSys to the Windows home, also known
as %USERPROFILE%. This would help new users, as well as uninstalling
(since the repositories would be outside of the installation directory),
but it would also involve changing existing setups, and we're close to
700 downloads for WinGit, and double that for msysGit.
This issue is not resolved yet.
^ permalink raw reply
* [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Sam Vilain @ 2007-10-05 3:09 UTC (permalink / raw)
To: git; +Cc: Sam Vilain
If the repository got mangled by FAT capitalization rules, then a ref
such as "HEAD" will become "head" once it is back on a non-FAT FS.
Check for this condition in resolve_refs and in the setup code.
Suggested-by: Francois Marier <francois@debian.org>
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
This should probably help people putting their git repos on
FAT USB sticks.
refs.c | 28 ++++++++++++++++++++++++----
setup.c | 7 +++++--
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 09a2c87..89ffb15 100644
--- a/refs.c
+++ b/refs.c
@@ -400,10 +400,30 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
}
list = list->next;
}
- if (reading || errno != ENOENT)
- return NULL;
- hashclr(sha1);
- return ref;
+ if (reading || errno != ENOENT) {
+ /*
+ * Hack for FAT-mangled ref filenames
+ */
+ if (strlen(ref) <= 8) {
+ char lc_name[9];
+ char* i;
+ strncpy(&lc_name, ref, 9);
+ for (i = lc_name; *i; i++) {
+ *i = tolower(*i);
+ }
+ path = git_path("%s", lc_name);
+ if (lstat(path, &st) < 0) {
+ return NULL;
+ }
+ }
+ else {
+ return NULL;
+ }
+ }
+ else {
+ hashclr(sha1);
+ return ref;
+ }
}
/* Follow "normalized" - ie "refs/.." symlinks by hand */
diff --git a/setup.c b/setup.c
index 06004f1..284d7b9 100644
--- a/setup.c
+++ b/setup.c
@@ -168,8 +168,11 @@ static int is_git_directory(const char *suspect)
return 0;
strcpy(path + len, "/HEAD");
- if (validate_headref(path))
- return 0;
+ if (validate_headref(path)) {
+ strcpy(path + len, "/head");
+ if (validate_headref(path))
+ return 0;
+ }
return 1;
}
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: Many gits are offline this week
From: alan @ 2007-10-05 1:59 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On Thu, 4 Oct 2007, Randal L. Schwartz wrote:
>>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Are you going to have the same heckler as the Advanced Topics meeting? ]:>
--
Never trust a queue structure designed by a cryptographer.
^ 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